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1.  INTRODUCTION 


1 . 1  STATEMENT  OF  THE  PROBLEM 


In  replacing  the  existing  National  Airspace  System  (NAS) 
computer  complex,  the  Federal  Aviation  Administration  ( FAA)  will 
choose  one  concept  for  computer  architecture  from  among  many 
possible  competitive  proposals.  The  system,  as  installed  by  the 
mid-1980's,  will  be  expected  to  have  a  useful  life  of  about 
twenty  years  and  to  meet  all  requirements  put  on  it  during  that 
time.  However,  requirements  change  with  time,  therefore,  it 
cannot  be  expected  that  the  1985  system  will  be  completely 
satisfactory  in  1995  and  beyond  because  of  possible  increasing 
traffic  loads  and  of  additional  funtions  to  be  performed.  It  is, 
then,  incumbent  on  the  FAA  to  choose  their  replacement  system 
wisely,  so  that  in  the  1980 's  they  will  have  a  system  which  can 
be  expanded  and  changed  enough  to  continue  to  serve  throughout 
its  expected  lifetime. 

At  the  same  time,  computer  technology,  both  in  hardware  and 
software,  is  changing  rapidly  so  that  a  system  designed  today  may 
be  obsolete  by  the  time  it  is  installed.  A  bigger  problem  is  the 
requirement  to  make  design  decisions  of  far  ranging  implications, 
without  benefit  of  practical  experience,  with  the  available 
alternatives.  This  is  the  problem  addressed  in  this  study. 

Specifically,  what  will  be  the  effect  in  the  1990 ' s  of  a 
choice  made  now  of  a  computer  architectural  concept  for 
installation  in  the  1980 's?  In  other  words,  the  attempt  is  made 
to  assess  not  how  well  each  computer  configuration  would  serve  as 
a  replacement  for  the  system,  meeting  the  requirements  of  1985, 
but  rather  how  well  it  might  perform  over  the  following  twenty 
years  or  so. 

1.2  METHOD  OF  ANALYSIS 

Before  this  analysis  can  begin,  the  proposed  computer 
architectural  concepts  for  the  Air  Traffic  Control  (ATC)  computer 
complex  must  be  obtained,  and  the  future  ATC  system  described. 

The  first  of  these  was  postulated  by  the  study  team,  and  the 
second  was  provided  by  the  sponsor. 

Four  generic  computer  configurations  were  identified  based 
roughly  on  concepts  already  suggested  as  possible  candidates. 

Each  configuration  was  abstracted  to  a  set  of  processors  with 
local  memory  connected  by  an  interprocessor  communications 
subsystem  whose  form  was  not  specified.  The  configurations  were 
then  differentiated  by  the  way  functions  were  assigned  to 
processors  and  the  possible  specialization  of  processors  to 
perform  in  different  ways.  The  four  configurations  selected  to 
this  point  cover  a  wide  range  of  possibilities  but  could  be 
supplemented  by  others  as  appropriate. 
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1 )  "Distributed"  System 

Processing  takes  place  either  at  the  source  of  the  data  to 
be  processed  or  at  the  location  where  the  output  is  used.  The 
functions  are  partitioned  into  sets  which  are  as  small  as 
practicable.  Each  set  is  assigned  to  a  single  processor  which 
can  then  be  specialized  for  that  set  of  tasks. 

2)  "Federated"  System 

The  system  is  made  up  of  a  number  of  identical  processors; 
each  is  assigned  a  set  of  functions  to  perform.  The  functions 
are  grouped  according  to  the  way  they  share  data,  and  groups  are 
assigned  to  processors  in  a  way  which  balances  the  load  among 
them.  The  assignment  of  functions  and  data  to  processors  does 
not  vary  with  time. 

3)  "Multi-Processor"  System 

The  system  is  similar  to  the  present  NAS  computer  complex, 
as  it  is  made  up  of  identical  processors  and  memory  modules 
arranged  so  that  any  processor  can  access  any  memory.  The 
processing  is  scheduled  dynamically  with  functions  assigned  to 
any  free  processor.  This  configuration  specializes  to  the 
uniprocessor  by  eliminating  redundant  processors. 

4)  "String-oriented"  System 

The  processing  is  organized  into  sequences  or  strings  of 
related  tasks;  each  of  which  is  assigned  to  a  set  of  processors 
arranged  in  pipeline  fashion.  Processors  can  be  specialized  for 
the  tasks  assigned  them. 

The  scenario  supplied  by  the  FAA  [see  Appendix  A]  describes 
the  structure  of  the  airspace,  the  distribution  of  traffic,  the 
surveillance  and  communications  modes,  and  the  new  and  improved 
services  to  be  rendered  by  the  ATC  system  from  the  mid-1 990's  on. 
This  view  of  the  world  is  only  one  of  many  possible  views,  but  it 
has  the  advantages  of  being  quite  general,  allowing  a  range  of 
independent  parameters  to  be  postulated,  and  of  being  quite 
demanding  of  the  ATC  system,  allowing  near  worst-case  conditions 
to  be  studied. 

The  methodology  followed  in  this  study  consisted  of  three 
steps  for  each  configuration  type. 

a)  A  "Baseline"  System  was  developed,  which  is  or  was  a 
version  of  the  candidate  configuration  sized,  with  functions 
assigned  to  processors  and  data  to  memories,  to  serve  as  the  en 
route  computer  complex  in  1985.  It  is  what  the  system  would  look 
like  if  this  configuration  were  chosen  for  implementation  as  the 
en  route  computer  system  replacement. 
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b)  Using  the  same  configuration,  the  "Future"  System  is 
developed.  New  traffic  loads  and  functions,  taken  from  the 
scenario,  are  postulated,  and  the  system  is  resized  and 
reconfigured,  where  necessary,  to  carry  out  the  new  functions. 

c)  The  analysis  of  the  implications  of  the  system  choice 
is  carried  out.  The  results  of  this  analysis  supply  the  answer 
to  the  question  posed  above. 

1.3  DESCRIPTION  OF  THIS  REPORT 

The  body  of  this  report  contains  the  material  from  each  of 
the  three  steps  of  the  methodology  for  the  first  of  the  four 
configuration  types,  the  "distributed"  system.  (It  is  expected 
that  the  remaining  types  will  be  the  subjects  of  later  volumes.) 
Section  2  contains  the  functional  description  of  the  Baseline 
System,  and  Section  3  describes  the  Future  System.  The  analysis 
of  the  implications  of  configuration  choice  is  given  in  Section 
4.  Three  appendices  follow:  Appendix  A  is  the  scenario  for  the 
Future  System  as  supplied  by  the  FAA,  Appendix  B  describes  the 
methods  used  to  get  traffic  estimates  for  1985  and  1995,  and 
Appendix  C  gives  the  results  of  a  related  background  study  on  the 
limitations  of,  and  possible  extensions  to,  the  current  IBM  9020® 
system. 
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2.  THE  BASELINE  SYSTEM 


2.1  ENVIRONMENT  OF  THE  BASELINE  SYSTEM 

The  "Baseline"  System  is  a  hypothetical  implementation  of 
the  ATC  en  route  system  as  it  might  appear  in  1985.  It  is 
assumed  that  an  IBM  9020®  replacement  computer  will  have  been 
procured  and  installed,  and  that  the  system  will  meet  the  1985 
functional  requirements. 

2.1.1  Surveillance 


It  is  assumed  that  by  1985  some  Discrete  Address  Beacon 
System  (DABS)  sensors  will  be  operational,  but  that  most  FAA 
sensors  will  still  be  combined  primary  and  Air  Traffic  Control 
Radar  Beacon  System  ( ATCRBS )  radars.  This  means  that  the 
computer  system  will  have  to  handle  both  types  of  data,  DABS  and 
ATCRBS,  in  a  mixed  environment.  It  is  assumed  that  data  coming 
from  DABS  equipped  aircraft  will  have  an  additional  DABS 
identification  associated  with  them. 


2.1.2  Communications 


It  is  assumed  that  the  National  Aviation  Data  Interchange 
Network  (NADIN)  system  will  be  used  for  inter-facility  and  remote 
communications  with  enough  bandwidth  available  so  that  there  is 
essentially  no  limit  on  communications  of  this  type.  This  means 
that  a  single  communications  interface  can  service  all  external 
sources  and  destinations,  since  there  will  be  a  common  interface 
standard  and  communications  protocol. 

Wherever  DABS  is  implemented,  the  DABS  data  link  will  be 
available,  hence  the  system  must  be  ready  to  use  it.  There  is 
the  implicit  assumption  that  some  aircraft  will  have  DABS  data- 
link  equipment  and  can  make  use  of  it. 

2.1.3  Interfaces 


The  NAS  computer  will  exchange  data  with  the  Central  Flow 
Control  Facility,  a  Weather  Services  facility,  and  a  Flight 
Service  facility  in  addition  to  adjacent  ATC  facilities.  Flow 
Control  messages  from  the  en  route  center  to  the  facility  will 
convey  information  about  non-scheduled  flight  plans,  changes  to 
flight  plans,  actual  departures  and  conditions  at  terminals; 
messages  flowing  in  the  other  direction  will  contain  delays  to  be 
imposed  on  scheduled  flights  and  other  flow  controlling 
directives.  The  Weather  Services  will  provide  both  map  and 
textual  data  describing  existing  and  predicted  weather  patterns 
and  events;  weather  information  derived  locally  and  from  pilot 
observations  will  be  transmitted  to  the  Weather  facility. 

Finally,  flight  plans,  filed  through  the  Flight  Service  Station 
(FSS),  will  be  received  by  the  en  route  computer,  which  will,  in 
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turn,  transmit  status  and  control  information  to  the  Flight 
Service  facility. 

2.1.4  Air  Activity 

Estimates  of  processing  and  communications  loads  on  the  1985 
system  will  depend  on  the  number  and  types  of  aircraft  being 
serviced  then,  as  well  as  the  particular  services  being  rendered. 
In  order  to  derive  estimates  of  the  required  parameter,  the 
traffic  figures  for  1975  (the  latest  available  as  this  study  was 
initiated)  were  assembled,  converted  to  required  measures,  and 
projected  to  1985.  The  process  is  described  in  detail  in 
Appendix  B. 

It  was  decided  to  carry  out  the  analysis  of  the  Baseline 
System  for  three  centers;  small,  medium,  and  large.  To  do  this, 
1975  data  from  three  actual  centers,  Denver,  Memphis,  and 
Chicago,  were  used  as  the  bases  for  projection  to  1985.  (Note: 

We  do  not  claim  to  be  predicting  the  traffic  at  those  actual 
centers  in  1985,  but  rather  what  the  traffic  at  typical  small, 
medium,  and  large  centers  might  be  in  1985.) 

The  parameters  chosen  to  describe  the  operation  of  the  en 
route  ATC  system  in  1985  are  given  in  Table  2.1-1  together  with 
the  values  assumed  to  hold,  at  that  time,  for  the  small,  medium, 
and  large  centers. 

2.1.5  Airspace  Structure 

It  is  assumed  that  the  structure  of  the  airspace  in  1985  is 
basically  what  it  is  today;  i.e.,  there  will  be  terminal-control, 
positive-control,  and  no-control  airspace.  It  is  assumed  that 
everything  above  12,500  feet  is  in  positive  control  airspace. 

2.1.6  En  Route  System  Functions 

The  set  of  functions  performed  by  the  Baseline  System  will 
include  those  performed  by  the  current  NAS  as  well  as  a  set  now 
under  development,  and  likely  to  be  developed  by  1985. 

The  current  NAS  functions  are: 

a.  Bulk  Store  Processing, 

b.  Flight  Plan  Activation, 

c.  Route  Conversion, 

d.  Posting  Determination, 

e.  Flight  Plan  Position  Extrapolation, 

f.  Fix-time  Calculation, 

g.  Associated  Checking, 

h.  Beacon  Code  Allocation, 

i.  Radar  Data  Preliminary  Processing, 

j.  Target/Track  Correlation, 

k.  Track  Acquisition, 

l.  Tracking  [Flight  Plan-Aided  Tracking  (FLAT)  and  Free) 

m.  Conflict  Alert, 
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TABLE  2.1-1  PARAMETERS  DESCRIBING  ATC  OPERATION  -  BASELINE  YEAR,  1985 


NO. 

PARAMETER 

SMALL 

CENTER 

MEDIUM 

LARGE 

1 

Number  of  Radar  Targets 
From  the  CDs  (Peak) 

[p] 

339 

533 

787 

2 

Number  of  Radars 

tnl 

9 

5 

5 

3 

Number  of  Tracks  in 
the  System  (Peak) 

ft) 

254 

400 

590 

4 

Number  of  Correlated 
Targets  (Peak) 

0.95  (#3) 

[tq] 

229 

361 

548 

5 

Number  of  Flight  Plans 
Entered  From  Bulk 

Store  (Busy  Hour) 

UB] 

85 

42 

227 

6 

Number  of  Flight  Plans 
in  Two-Minute  Interval 
From  Bulk  Store 

U21 

3 

1 

7 

7 

Number  of  Flight  Plans 
Entered  Through  FSSs 
(Busy  Hour) 

Upl 

42 

175 

137 

8 

Number  of  Active  Flight 
Plans  in  the  System 
(Peak) 

[»A1 

430 

668 

984 

9 

Number  of  Displays 
(Sectors) 

[e] 

34 

36 

43 

10 

Number  of  Controller 
Operations  (Per 

Minute  Per  Position) 

[6crJ 

4 

4 

4 

11 

Number  of  Uncorrelated 
Radar  Returns  (Peak) 

0.01  (#3) 

tPpl 

2 

4 

6 

12 

Number  of  Conflicts 
Predicted  per  Hour 

tv] 

58 

144 

333 

13 

Number  of  Departures/ 
Arrivals  (Busy  Hour) 

[w 

126 

216 

364 

14 

Number  of  Overflights 
(Busy  Hour) 

[♦ol 

130 

152 

87 

■ 

Number  of  D  Controller 
Operations  (Per 

Minute  Per  Position) 

^CD^ 

6 

6 

6 

16 

Number  of  MSAW  Conflicts 
Detected  per  Hour 

lb] 

6 

12 

30 

17 

Number  of  Flight  Plan 
Amendments  Entered 
per  Hour 

UH] 

2040 

2160 

2580 

18 

Number  of  Flight  Plans 
Activated  per 

Hour 

[*H] 

254 

434 

728 

19 

Number  of  Flight  Plan 
Entries  per  Display 

[*DI> 

24 

36 

46 

n.  Display  Generation, 

o.  Display  Control, 

p.  Message  Processing, 

q.  Data  Base  Management, 

r.  Real-time  Quality  Control  of  Radar  Data, 

s.  System  Data  Recoding, 

t.  Dynamic  Simulation, 

u.  Critical  Data  Recording,  and 

v.  Supervisory  Functions. 

Functions  which  are  currently  under  development  and  which 
could  be  expected  to  be  in  place  by  the  late  1980's  include: 

1)  En  Route  Metering, 

2)  Flight  Plan  Probe, 

3)  Minimum  Safe  Altitude  Warning  (MSAW),  and 

4)  Conflict  Resolution  (First  Stage). 

Certain  subsystems  interface  with  the  IBM  9020®  now,  or  will 
in  the  future.  These  are: 

a)  Display  Channel, 

b)  Direct  Access  Radar  Channel  (DARC), 

c)  Electronic  Tabular  Display  System  (ETABS), 

d)  Weather  Processing,  and 

e)  FSS. 

*  Of  these,  it  is  assumed  that  the  Display  Channel  functions  are 
carried  out  by  the  new  system  itself  and  that  the  Display  Channel 
equipment  has  been  moved  out  with  the  Central  Computer  Complex 
(CCC)  equipment.  The  DARC  equipment  will  not  be  needed  and  will 
also  be  moved  out.  The  ETABS  equipment  will  be  retained;  it  is 
assumed  that  it  can  be  incorporated  into  the  Baseline  System 
easily.  It  is  assumed  the  the  FSS  and  Weather  Processing  systems 
interface  as  described  above.  (Section  2.1.3). 

It  is  also  assumed  that  the  Baseline  System  will  support  the 
Central  Flow  Control  function  and  will  make  use  of  its  outputs 
where  appropriate  (Section  2.1.3.) 

2.2  FUNCTIONAL  DESCRIPTION  OF  THE  BASELINE  SYSTEM 

The  first  step  in  what  is  essentially  a  preliminary  system 
design  process  is  the  preparation  of  a  functional  description  of 
the  system.  The  description  should  be  implementation- 
independent,  showing  neither  hardware  nor  operating-system 
dependencies. 

2.2.1  Functional  Organization  of  the  Baseline  System 

The  functional  organization  of  the  Baseline  System  is 
described  here  in  a  block  diagram  and  a  set  of  accompanying 
tables.  The  diagram,  Figure  2.2-1,  shows  the  static  relationship 
among  the  functions  and  the  flow  of  information  through  the 
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system.  The  tables,  Tables  2.2-1  through  2.2-4,  describe  the 
processing  in  a  few  words  and  list  information  received  and 
produced  along  with  source  and  destination. 

In  the  diagram,  functions  are  represented  as  rectangular 
boxes.  Each  function  accepts  one  or  more  message  or  data  files 
as  input  and  produces  one  or  more  as  output;  these  are 
represented  as  boxes  with  curved  bottoms.  System  inputs  and 
outputs  are  represented  by  octagonal  boxes.  The  inputs  enter 
from  the  left,  and  outputs  leave  at  the  right.  There  is  a 
tendency  for  information  to  flow,  therefore,  from  left  to  right, 
although  locally  the  four  data  bases — Flight  Data,  Operational 
and  Environmental  Data,  Track  Data  and  Display  Data — serve  as 
points  of  accumulation. 

In  preparing  the  tables,  the  functions  were  grouped  under 
three  primary  and  three  support  headings.  The  primary  category 
consists  of  radar  data  processing,  track  data  processing,  and 
flight  data  processing,  while  the  support  group  consists  of 
display  processing,  message  processing,  and  data  base  management. 
No  tables  were  prepared  for  the  last  two  groups  since  the 
activities  of  these  functions  seem  too  straightforward  to  warrant 
explanation. 

2.2.2  Character ist i cs  of  Functions 

A  set  of  operational  characteristics  with  which  the  system 
may  be  described  has  been  compiled  and  is  listed  below.  An 
attempt  has  been  made  to  define  characteristics  that  are 
implementation-free,  that  depend  on  the  properties  of  the 
functions  and  their  roles  in  system  operation.  Characteristics 
such  as  response  time  and  operational  role  of  the  function  are 
virtually  independent  of  the  implementation  because  they  are 
derived  from  the  functional  requirements.  Others,  such  as  amount 
of  storage  requirement  and  amount  of  processing  per  operation, 
depend  to  a  greater  or  lesser  degree  on  how  the  functions  are 
implemented.  Without  knowledge  of  the  implementation,  the  values 
of  these  characteristics  cannot  be  stated  precisely,  and 
therefore  they  are  measured  in  order-of -magnitude  terms  only. 

There  are  two  points  to  be  made.  First,  for  the  purpose  of 
this  study,  the  values  of  the  characteristics  as  derived  are 
sufficient.  There  is  no  attempt  being  made  to  fix  on  any  one 
implementation  or  group  of  implementations,  or  even  a  particular 
level  of  technology,  but  rather  to  evaluate  concepts.  Second, 
the  attempt  to  derive  more  exact  expressions  is  both  fruitless 
and  unwise.  More  precision  not  available  without  assumptions 
which  would  limit  the  extent  of  the  study. 

2. 2. 2.1  Amount  of  Storage  Required  -  This  includes  space  for  the 
program,  incidental  data  and.  work  space  but,  specifically,  does 
not  include  the  relevant  data  base.  It  is  expressed  as  small, 
medium,  large,  or  very  large,  where: 
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TABLE  2.2-1  RADAR  DATA  PROCESSING 
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TABLE  2.2-2  (CONTINUED) 


small  <  5,000  bytes, 

5,000  <  medium  <  20,000  bytes, 

20,000  <  large  <  100,000  bytes, 

100,000  <  very  large. 

2. 2. 2. 2  Amount  of  Processing  per  Program  Operation  -  "Amount  of 
Processing"  represents  both  the  number  of  instructions  executed 
and  the  complexity  of  the  instruction  mix.  "Program  Operation" 
must  be  defined  for  each  function  and  may  depend  on 
implementation. 

Two  types  are  distinguished: 

Type  1:  The  program  operates  on  whatever  data  is  available. 

(The  amount  depends  on  the  system  load).  The  amount  of 
processing  is  expressed  as  a  function  of  the  system 
load  components  with  coefficients  depending  on  type  of 
processing.  For  example, 

P  =  +  K2  L  +  K3M 

where  L,  M  are  components  of  the  system  load. 

Type  2:  The  program  operates  on  a  constant  amount  of  data 

independent  of  system  load.  The  amount  of  processing 
is  expressed  as  a  constant. 

P  *  K. 

The  coefficients,  K,  K,,  K*,  and  K,,  are  expressed  as 
small,  medium,  and  large  according  to  the  type  of  processing: 

small  -  e.g.  simple  request  for  data 

medium  -  e.g.  flight  plan  position  calculation 

large  -  e.g.  tracking. 

As  a  rule  of  thumb,  the  amount  of  processing  for  each 
level  is  ten  times  the  preceding;  i.e.,  if  small  «  x,  then  medium 
«  lOx,  large  ■  lOOx,  reflecting  the  order-of -magnitude  sizing 
discussed  earlier. 

2. 2. 2. 3  Frequency  of  Operation  (Duty  Cycle)  -  This  is  an 
expression  of  how  often  the  program  operates  and  of  how  regular 
the  operation  is.  If  the  function  is  operated  periodically,  the 
frequency  is  expressed  as: 

once/30  minutes  (e.g.,  bulk  storage  processing) 

once/minute  (e.g.,  flight  plan  activation) 


2-14 


once/1 Oseconds  (e.g.,  surveillance) 
once/second  (e.g.,  display  processing) 
once/millisecond  (e.g.,  data  base  management) 

Other  rates  are  also  possible. 

If  the  frequency  is  not  constant,  we  assume  it  is  aperiodic; 
(i.e.',  we  disregard  the  possibility  that  the  function  is 
periodic,  but  some  load-sensing  mechanism  changes  the  frequency 
so  that  it  is  step-wise  variable).  The  average  rate  is, 
therefore,  given  as  a  function  of  load, 

4>  =  f(D 

and  an  indication  is  given  of  the  variability: 
nearly  uniform 
fluctuating 
erratic. 

Other  possibilities,  such  as  response  to  either  a  buffer-full 
condition  or  interval  time-out,  will  be  considered  as  special 
cases  depending  on  implementation. 

The  frequency  of  operation  may  be  dictated  by  considerations 
external  to  the  function  itself,  such  as  the  need  to  respond  to 
another  function  or  to  provide  a  timely  input  to  another 
function.  The  rationale  used  in  estimating  frequency  should  be 
explained. 

2. 2. 2. 4  Type  of  Processing  -  Estimates  are  made  of  the 
percentages  of  the  processing  in  each  of  the  classes: 

I/O 

Calculation 

Logical 

Character  (String)  Processing 
Matching  or  Sorting 

2. 2. 2. 5  Amount  of  Data  in  and/or  Out  per  Program  Operation  - 
Program  operation  should  be  defined  as  in  2. 2. 2. 2.  The  amounts 
of  data  are  expressed  as  functions  of  the  load  components  as  was 
done  there.  The  coefficients  are  expressed  as  small  though  very 
large  according  to  the  ranges: 


small  <  20  bytes, 

20  <  medium  <  200  bytes, 

200  <  large  <  2,000  bytes, 

2,000  <  very  large. 

2. 2. 2. 6  Response  Time  -  This  is  an  estimate  of  the  response 
requirement  on  this  function  as  imbedded  in  the  system,  taking 
into  account  the  overall  system  performance  requirements.  It  is 
expressed  as,  for  instance: 

<  1  second 

<10  seconds 
>10  seconds 

These  estimates  are  based  on  performance  requirements  which  may 
not  remain  fixed;  i.e.,  they  may  depend  on  a  particular  set  of 
functions  being  included. 

2. 2. 2. 7  Operational  Role  of  the  Function  -  This  is  the  basic 
role  the  function  plays  in  system  operation.  Suggested 
categories  are: 

processes  primary  input, 

produces  primary  output, 

produces  supplementary  output, 

develops  basic  data,  and 

provides  support  service. 

2. 2. 2. 8  Dependence  on  Other  Functions  -  This  should  be  a  short 
description  of  how  this  function  is  related  to  the  other 
functions.  Suggested  categories  are: 

Independent  -  asynchronous,  uses  no  special  derived  data, 

Runs  only  when  called  by  another  function. 

Requires  data  developed  by  another  function. 

Other  categories  are  needed.  A  function  may  fit  into  many 
categories  simultaneously. 

2.2.3  Characteristics  of  the  Baseline  Functions 

The  characteristics  developed  above  have  been  compiled  for 
the  functions  which  make  up  the  Baseline  System.  These  are 
listed  in  Table  2.2-5. 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 


Storage 


RADAR  DATA —  PREL IMI NARY  PROCESSING 


Program  operates  once  for  each  buffer  Load  from  each 
sensor. 


Med ium 

(Buffer  space  for  data  in  and  out  is  largest  factor.) 


Processing 
per  Operation 


P  =  kl  +  k2r 

Where  R  is  the  number  of  radar  targets  from  the  CD. 
=  small,  K2  *  medium 


Frequency 
of  Operation 


Program  must  service  all  CDs  within  space  of  about 
1  second.  It  probably  would  operate  periodically 
then,  ~  once/sec/radar. 


Types  of 
Processing 


I/O  20% 
Calc. 60% 
Log.  10% 


Char.  0 
Match.  10% 


Amount  of 
Data 


Response 

Time 


In:  D  *  Kj  +  K^R  Out:  D  ■  K  +  K  R 

R  is  the  number  of  radar  R  is  the  number  of  radar 
targets  targets 

Kj  =  medium,  *  small  =  medium,  K2  =  small 


<  1  second 

Dictated  by  requirement  to  deliver  radar  data  to  the 
display  within  time  limit  prescribed  by  performance 
requirements  (plus  need  to  service  the  sensors) 


Operational 

Role 


Processes  primary  input 


Dependence 


Independent,  asynchronous  of  other  functions 


TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


REAL-TIME  QUALITY  CONTROL 

Operates  periodically  (function  of  radar  scan  rates) 
and  on  demand 

I 

Storage 

Small 

II 

Processing 
per  Operation 

P  =  Kj  +  K^N,  where  N  is  the  number  of  radars  in  the 
system 

Kj  =  small,  =  medium 

III 

Frequency 
of  Operation 

Once  per  radar  scan 
~  10  sec. 

IV 

Types  of 
Processing 

I/O  0 

Calc.  80%  Char.  0 

Log.  20%  Match.  0 

V 

Amount  of 

Data 

In:  D  =  KlN  Out:  D  =  K 

where  *  medium  where  K  =  small 

N  =  number  of  radars 

VI 

Response 

Time 

~  1  second 

Dictated  by  the  need  to  compute  and  apply  correction 
factors  to  the  data  from  the  next  scan 

VII 

Operational 

Role 

Provides  support  service 

VIII 

Dependence 

Requires  data  from  Preliminary  Processing  and  Target/ 
Track  Correlation 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


TARGET/TRACK  CORRELATION 

Once  for  each  operation  of  that  program,  or  perhaps 
once  once  per  n  operations  where  n  is  small 

1 

Storage 

Small 

(could  be  medium  if  buffer  space  needed) 

II 

Processing 
per  Operation 

P  =  Kx  +  K2R  +  K3R  log2T 

where  R  =  no.  of  radar  returns,  T  •  no.  of  tracks  in 
system 

*  small,  K2  =  small,  =  small 

III 

Frequency 
of  Operation 

Program  must  handle  all  the  data  from  Preliminary 

Processing  periodically,  ~  once/sec/radar  or  ~ 
once/sec/n  radars 

IV 

Types  of 
Processing 

y?  ,A.  Char.  0 

SI!’  »> 

V 

Amount  of 

Data 

In:  D  =*  +  K2R  +  K  T  Out:  D  =  +  K2R 

R=  no.  of  radar  targets,  T  =  R  =  no.  of  radar  targets 

no.  of  tracks  »  medium,  K2  *  small 

Kj  =  medium,  K  "small,  K3=small 

VI 

Response 

Time 

<  1  second 

Program  must  meet  same  response  requirment  as  Preliminary 

Processing 

VII 

Operational 

Role 

Processes  primary  input 

Develops  basic  data  (part  of  Track  Data  D.B.) 

vTTT" 

Dependence 

Processes  data-stream  from  Preliminary  Processing 

- - — . . . . —— .  . — 
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TABLE  2.2.5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  "UNCTIONS 


(^CONTINUED) 


DYNAMIC  SIMULATION 

Operates  only  when  specifically  requested,  then  operates 
cyclically,  synchronized  with  radar  data  input 

I 

Storage 

Small 

n 

Process ing 
per  Operation 

P  =  Kj  +  1^2  Tg  where  Tg  is  the  number  of  simulated  targets. 
=  small,  K2  =  large 

III 

Frequency 
of  Operation 

Operates  about  once  per  second. 

IV 

Types  of 
Processing 

I/o  0  Char.  0 

Calc  60%  Match.  0 

Log  40% 

V 

Amount  of 

Data 

In:  D  =  K  Out:  D  =  KT 

s 

where  K  is  small  where  T  is  the  number  of 

simulated  targets  K  =  medium 

VI 

Respon se 

Time 

^1  second 

VII 

Operational 

Role 

Provides  supplementary  service 

VIII 

Dependence 

Operates  independently  of  the  rest  of  the  system 

2-20 


TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


4 


BULK  STORE  PROCESSING 

Each  operation  reads  in  a  number  of  flight  plans,  such  that 
the  start  times  span  about  30  minutes. 

1 

Storage 

Med ium 

(mostly  buffer  space) 

11 

Processing 
per  Operation 

P  =  K1 

where  =  small 

III 

Frequency 
of  Operation 

Periodic 

~  once/10  minutes 

IV 

Types  of 
Processing 

?'?  8°*  Char.  15* 

8,Ic'  L  Match.  0 

Log.  5% 

V 

Amount  of 

Data 

In:  D.-  Kj  +  K  F  Out :  D  =  ^  +  D^ 

F  =  number  of  flight  plans  (Din  =  Dout) 

,K^  ■  small,  K2  =  medium 

VI 

Response 

Time 

No  particular  response  time  requirement 

VII 

Operational 

Role 

Processes  primary  input 

VIII 

Dependence 

Independent,  asynchronons  of  other  functions 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


Storage 


FLIGHT  PLAN  ACTIVATION 


Operates  on  all  flight  plans  due  in  next  two  minutes, 
then  sets  timer  for  trigger  when  next  flight  plan  is  due. 


1  Small 


Processing  P  -  +  K^F 

per  Operation  where  F  is  the  number  of  flight  plans  due  in  the  next  2 
minutes  *  small,  =  medium 


III  Aperiodic,  ..  once/2  minutes,  nearly  uniform  under  high 
Frequency  *oad 

of  Operation  Depends  on  number  of  flight  plans 


IV  1/0  ° 

Calc.  0 

Types  of  Log.  25% 

Processing 


Char.  75% 
Match.  0 


Amount  of 
Data 


In:  D  =  K  +  K2F 
where  F  =  number  of  flight  plans 
=  small,  K2  =  medium 


Out:  D  =  K 

where  K  =  medium 


No  particular  response  time  requirement 


Response 

Time 


Operational  Processes  primary  input  to  Flight  Data  D.B. 

Role 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


BEACON  CODE  ALLOCATION 

Operates  once  for  each  request  for  beacon  code  or  release 
of  beacon  code 

I 

Storage 

Small 

II 

Processing 
per  Operation 

P  =  Ki 

where  =  small 

III 

Frequency 
of  Operation 

Aperiodic,  ~  once/second,  depending  on  the  number  of  active 
fluctuating  flight  plans 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  0  Match.  0 

Log.  100% 

V 

Amount  of 

Data 

In:  D  =  K  Out:  D=K 

where  K  _ small  where  K  *  small 

VI 

Response 

Time 

<  1  second 

VII 

Operational 

Role 

Develops  basic  data 

VIII 

Dependence 

Runs  when  called  by  request 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


ROUTE  CONVERSION 

Operates  once  for  each  flight  plan  activation  or  flight 
plan  change 

I 

Storage 

Large 

II 

Process ing 
per  Operation 

P1  ‘  K!  P2  '  K2 
where  =  large  where  =  medium 

(for  flight  plan  (for  flight  plan 

activation)  amendment) 

III 

Frequency 
of  Operation 

Aperiodic,  ~  once/second ,  nearly  uniform 
depends  on  number  of  flight  plans 

IV 

Types  of 
Processing 

I/O  0  Char.  40% 

Cal.  20%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  =  K  Out:  D  =  K 

K  =  large  K  =  medium 

VI 

Response 

Time 

<  10  seconds 

Mostly  response  to  flight  plan  change  message. 

VII 

Operational 

Role 

Develops  basic  data 

VIII 

Dependence 

Processes  input  stream  from  Flight  Plan  Activation 

Also  operates  independently  upon  external  request 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


POSTING  DETERMINATION 

Each  operation  either  processes  whole  converted  flight 
plans  or  changes  as  produced  by  Route  Conversion,  or 
it  posts  the  fixes  due  in  the  next  interval. 

I 

Storage 

Small 

II 

Process ing 
per  Operation 

P1  =  K1  P2  K2 

where  =  large  where  K  =  medium 

(for  whole  flight  plans)  (for  single  interval) 

III 

Frequency 
of  Operation 

Operates  after  each  run  of  Route  Conversion  plus  when 
triggered  by  the  interval  timer 

aperiodically  ~  once/sec  depending  on  number  of  flight 
plans  fluctuating 

IV 

Types  of 
Processing 

I/O  40%  Char.  30% 

Calc.  0  Match.  20% 

Log.  10% 

V 

Amount  of 

Data 

In:  D  =  K  Out :  D  =  K 

K  =  medium  K  =  small 

VI 

Response 

Time 

;  10  second 

VII 

Operational 

Role 

Develops  basic  data 

Produces  and  triggers  primary  output 

VIII 

Dependence 

Processes  input  stream  from  Route  Conversion 

Responds  to  interval  timer 

TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


FLIGHT  PLAN  POSITION  EXTRAPOLATION 

Operates  on  all  flight  plans  periodically 

1 

Storage 

Small 

II 

Processing 
per  Operation 

P  =  K 

where  K  =  medium 

III 

Frequency 
of  Operations 

Periodic  ~  once/30  sec. 

Operates  on  fraction  of  active  flight  plans  such  that 
each  flight  plan  is  processed  once/5  minutes 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  60%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  =  KjF  Out:  D  =  K^F 

where  F  is  the  number  of  flight  plans 

Kj  “  medium,  =  small 

VI 

Response 

Time 

<  10  seconds 

VII 

Operational 

Role 

Develops  basic  data 

VIII 

Dependence 


Asynchronous  with  other  functions 
Processes  data  as  available 


TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


FIX-TIME  CALCULATION 

Operates  when  called  by  Posting  Determination  or  Flight 
Plan  Position  Extrapolation 

I 

Storage 

Small 

II 

Processing 
per  Operation 

P  =  K1 

where  =  medium 

III 

Frequency 
of  Operation 

Aperiodic,  _  once/.l  second,  fluctuating 
depending  on  the  number  of  flight  plans 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  60%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  =  Out:  D  =  K2 

where  ■  medium,  K2  =  small 

VI 

Response 

Time 

<.l  second,  in  order  to  maintain  system  operation 

VII 

Operational 

Role 

Develops  basic  data 

Operates  as  subfunction,  supplies  specialized  service 

VIII 

Dependence 

Operates  when  called 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


ASSOCIATION  CHECKING 

Operates  on  all  matched  flight  plans  periodically 

I 

Storage 

Small 

II 

Processing 
per  Operation 

P  -  K  +  K2F 

where  F  is  the  number  of  flight  plans 
=  small,  K2  =*  medium 

III 

Frequency 
of  Operation 

Periodic,  ~  once/30  seconds 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  60%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  =  K^F  Out:  D0  =  KjF 

where  F  =  the  number  of  flight  plans 
=  medium,  kj  ~  small 

VI 

Responae 

Time 

<10  seconds 

VII 

Operational 

Role 

Develops  basic  data 

Produces  control  information 

vin 

Dependence 

Asynchronous  with  other  data 

Processes  data  as  available 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


Storage 


FLIGHT  PLAN  PROBE 


Operates  on  all  flight  plans  periodically 


Process ing 
per  Operation 


P  =  Kx  +  K2F  log2F 

where  F  is  the  number  of  flight  plans 
=  small,  K2  =  mediun 


Frequency 
of  Operation 


~  once/10  minutes 
periodic 


Types  of 
Processing 


I/O  0 
Calc.  20% 
Log.  10% 


Char.  0 
Match.  70% 


mount  of 
ata 


In:  D  *  KjF 


Out:  D  «  K2F 


where  F  =  number  of  flight  plans 
=  medium,  K2  =  small 


Response 


Operational 

Role 


Develops  secondary  output 


Dependence 


Asynchronous,  timing  independent  of  other  functions 
Uses  available  data. 


TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


EN  ROUTE  METERING 


Operates  on  each  flight  at  prescribed  fixed  and/or 
times 


1 

Storage 

Med ium 

II 

Processing 
per  Operation 

p'Ki 

where  =  medium 

III 

Frequency 
of  Operation 

Aperiodic,  ~  once/five  minutes  for  each  flight  in  the 
system 

IV 

Types  of 
Processing 

1 

0  0  Char.  102 

lc.  40%  Match.  0 

g.  50% 

V 

Amount  of 

Data 

In:  D  =  Out:  D  * 

where  =  medium  ^  =  medium 

VI 

Response 

Time 

<  10  seconds,  to  ensure  timeliness  of  results 

VII 

Operational 

Role 

Develops  secondary  output 

'iii 


(Dependence 


Depends  on  data  from  Association  Checking  and  Flight 
Plan  Extrapolation  functions 
Responds  to  internal  timer 


TABLE  2.2-S  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


DISPLAY  GENERATION 

Each  operation  processes  the  data  for  all  displays. 

1 

Storage 

Large 

II 

Processing 
per  Operation 

P  =  K,  +K„F  +  K  F  D. 

1  2  3  1 

where  F  =  number  of  flight  plans,  D,  =  number  of  displays 
=  medium,  =  medium,  =  medium 

III 

Frequency 
of  Operation 

Periodically,  ~  once/10  sec 

Synchronized  with  radar  scan 

IV 

Types  of 
Processing 

I/O  0  Char.  30% 

Calc.  30%  Match.  20% 

Log.  20% 

V 

Amount  of 

Data 

In:  D  =  Kx  +  ^F  Out:  D  =  (K3  +  KjF^ 

where  F  ■  number  of  flight  plans,  D.  =  number  of  displays 
=  large,  =  medium,  =  large,  *  medium 

VI 

Response 

Time 

<10  sec, 

VII 

Operational 

Role 

Produces  primary  output 

- vTTT 

Dependence 

Independent,  asynchronous 

Uses  available  data 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


TRACK  ACQUISITION 

Operates  once  per  basic  system  cycle, 

~  twice  per  radar  scan 

I 

Storage 

Small 

II 

Processing 
per  Operation 

P  "  K!  +  K2R 

where  R  **  number  of  uncorrelated  radar  returns 
=  small,  K2  =  medium 

III 

Frequency 
of  Operation 

Periodic,  ~  once/5  sec. 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  20%  Match.  60% 

Log.  20% 

V 

Amount  of 

Data 

In:  D  =  KjR  Out:  D  =  K2R 

where  R  =  number  of  uncorrelated  radar  returns 
=  medium,  Kj  =  small 

VI 

Response 

Time 

<  10  sec. 

VII 

Operational 

Role 

Processes  primary  input 

VIII 

Dependence 

Synchronized  with  Target/Track  Correlation 

Uses  data  from  Target/Track  Correlation 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


TRACKING  (Free) 

Operates  once  per  basic  system  cycle  on  all  available 
data 

I 

Storage 

Small 

II 

Processing 
per  Operation 

P  "  WfA 

where  TpR  is  the  number  of  tracks  being  free-tracked 
=  small,  Ko  =  large 

III 

Frequency 
of  Operation 

Periodic,  ~  once/5  sec. 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  60%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  -  K1TpR  Out:  D  K2TFR 

where  TpR  =  number  of  tracks  being  free-tracked 
=  medium,  =  medium 

VI 

Response 

Tine 

<  1  second 

VII 

Operational 

Role 

Processes  basic  data 

VIII 

Dependence 

Synchronized  with  Target/Track  Correlation 

Uses  data  from  Target/Track  Correlation 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


TRACKING  (FLAT) 


Operates  once  per  basic  system  cycle  on  all  available 
data 


1 

Storage 

Small 

II 

Processing 
per  Operation 

p  =  Ki  +  Vfl 

where  T  =  number  of  tracks  being  FLAT-tracked 

r  L 

=  small,  =  large 

III 

Frequency 
of  Operation 

Periodic,  ~  once  5 /sec 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  60%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  =  Kx  T^  Out:  D  . 

where  T  *  number  of  tracks  being  FLAT-tracked 

r  L 

VI 

Response 

Time 

<  1  second 

VII 

Operational 

Role 

Processes  basic  data 

VIII 

Dependence 

Synchronized  with  Target/Track  Correlation 

Uses  data  from  Target/Track  Correlation,  Association 
Checking  and  Flight  Plan  Position  Determination 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


CONFLICT  ALERT 

Each  operation  processes  all  tracks 

1 

Storage 

Medium 

II 

Processing 
per  Operation 

P  =  ^  +  K2T  log2T 

where  T  is  number  of  tracks 
=  small,  K2  =  medium 

III 

Frequency 
of  Operation 

Periodic,  ~  once/minute 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  20%  Match.  70% 

Log.  10% 

V 

Amount  of 

Data 

In:  D  =  KjT  Out:  D  =  K2T 

where  T  =  number  of  tracks 
=  medium,  K2  =  small 

VI 

Response 

Time 

~  10  sec. 

VII 

Operational 

Role 

Produces  supplementary  output 

‘  VIII 

Dependence 


Asynchronous,  independent 
Uses  available  data 


TABLE  2.2-S  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


Storage 


CONFLICT  RESOLUTION 


Each  operation  processes  all  conflicts 


n  p  =  Ki  +  k2  c 

where  C  =  number  of  conflicts 


Processing  where  C  =  number  or  coi 

per  Operation  =  small,  K2  =  large 


HI  I  Periodic,  ~  once/minute 


Frequency 
of  Operation 


I/O  0 
IV  Calc.  60% 
Types  of  Log*  40% 

Processing 


Char .  0 

Match.  0 


Amount  of 
Data 


V  In:  D  =  K^C 


Out:  D  =  K2C 


where  C  =  number  of  conflicts 
=  medium,  K2  =  medium 


Response 

Time 


Operational 

Role 


Produces  supplementary  output 


Dependence 


Synchronized  with  Conflict  Alert 
Uses  data  from  Conflict  Alert 


1 


TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


MSAW 

Operates  on  all  tracks  in  system 

I 

Storage 

Medium 

II 

Processing 
per  Operation 

P  =  Ki  +  k2t 

where  T  =  number  of  tracks 
=  small,  K2  =  medium 

III 

Frequency 
of  Operation 

Periodic,  ~  once/30  seconds 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  60%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  =  KjT  Out:  D  =  K2T 

where  T  is  the  number  of  tracks 
=  medium,  K2  =  small 

VI 

Response 

Time 

<10  sec. 

VII 

Operational 

Role 

Produces  supplementary  output 

VIII 

Dependence 


Asynchronous,  independent 
Uses  available  data 


TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


1 


MESSAGE  PROCESSING 

Operates  once  per  message  processed 

I 

Storage 

Medium 

II 

Processing 
per  Operation 

P  =  K! 

where  =  medium 

III 

Frequency 
of  Operation 

Aperiodic,  ~  once/ 10  msec, 
fluctuating 

IV 

Types  of 
Processing 

I/O  40%  Char.  40% 

Calc.  0  Match.  0 

Log.  20% 

V 

Amount  of 

Data 

In:  D  =  Out:  D  *  ^ 

where  =  small,  ^  ■  small 

VI 

Response 

Time 

<1  second 

VII 

Operational 

Role 

Processes  basic  data 

Controls  distribution  of  data  and  control  information 
Provides  fundamental  service 

VIII 

Dependence 

Asynchronous,  independent 

TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


O&E  D.B.M. 


Operates  once  per  data  request  or  response 


Storage 


Processing 
per  Operation 


where  =  small 


Frequency 
of  Operation 


Aperiodic,  ~  once/millisecond 
fluctuating 


Types  of 
Processing 


I/O  0 
Calc.  10% 
Log.  40% 


Char.  50% 
Match.  0 


V  In:  D  =  K, 


Out:  D  =  K„ 


Amount  of 
Data 


where  =  small/medium,  "  medium/ small 


Response 

Time 


Operational 

Role 


Processes  basic  data 
Provides  fundamental  service 


mu 


Dependence 


Asynchronous,  independent 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


CRITICAL  DATA  D.B.M. 

Operates  cyclically  as  data  is  collected  and  (rarely) 
during  recovery  and  restart  operations 

1 

Storage 

Small 

11 

Process ing 
per  Operation 

P  =  K! 

where  =  small  during  normal  operations 

=  large  during  recovery 

III 

Frequency 
of  Operation 

~  once/millisecond  during  normal  operations 

IV 

Types  of 
Processing 

I/O  0  Char.  50% 

Calc.  10%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  -  Kx  Out:  D  =  K2 

=  small  (normal)  K2  ■  very  large  (recovery) 

VI 

Response 

Time 

<  10  sec  (normal) 

<  1  sec  (recovery) 

VII 

Operational 

Role 

Supports  recovery  and  restart  only 

VIII 

Dependence 

Asynchronous ,  independent 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


SYSTEM  PERFORMANCE  D.B.M. 


Operates  cyclically  as  data  is  collected 


Storage 


II  P  «  K. 

Processing  1 

per  Operation  where  is  small 


Frequency 

of  Operation  -  once/millisecond 


I/O  0 
IV  Calc.  10% 
Types  of  Log.  40% 

Processing 


Char.  50% 
Match.  0 


V  In:  D  -  K, 


Amount  of 
Data 


“  small 


Response 

Time 


Operational 

Role 


(Dependence 


Asynchronous,  Independent 


TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


FLIGHT  DATA  D.B.M. 

Operates  once  per  data  request  or  response 

I 

Storage 

Small 

II 

Processing 
per  Operation 

P  =  K1 

where  55  small 

III 

Frequency 
of  Operation 

Aperiodic,  ~  once  millisecond 
fluctuating 

IV 

Types  of 
Processing 

1/0  0  Char.  50% 

Calc.  10%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  =  K1  Out:  D  =  K2 

where  *  amall/medium,  K2  ■  medium/ small 

VI 

Respun se 

Time 

<10  sec. 

VII 

Operational 

Role 

Processes  basic  data 

Provides  fundamental  service 

’  ■■  "mr 

Depend 

Asynchronous,  Independent 
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TABLE  2.2-5  OPERATIONAL  CHARACTERISTICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


TRACK  DATA  D.B.M. 

Operates  once  per  data  request  or  response 

I 

Storage 

Small 

II 

Processing 
per  Operation 

P  =  K! 

where  =  small 

III 

Frequency 
of  Operation 

Aperiodic,  ~  once/millisecond 
fluctuating 

IV 

Types  of 
Processing 

I/O  0  Char.  50% 

Calc.  10%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  *  Kx  Out:  D  *  K2 

where  *  small/medium,  Kj  *  medium/ small 

VI 

Response 

Time 

<10  sec. 

VII 

Operational 

Role 

Processes  basic  data 

Provides  fundamental  serivce 

VIII 

Dependence 

Asynchronous,  independent 
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TABLE  2.2-5  OPERATIONAL  CHARACTERI STICS  OF  BASELINE  FUNCTIONS 

(CONTINUED) 


DISPLAY  DATA  D.B.M. 

Operates  once  per  data  request  or  response 

I 

Storage 

Small 

II 

Processing 
per  Operation 

P  =  K! 

where  =  small 

III 

Frequency 
of  Operation 

Aperiodic,  ~  once/millisecond 
fluctuating 

IV 

Types  of 
Processing 

I/O  0  Cnar.  50% 

Calc.  10%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  =  K1  Out:  D  =  K2 

where  =  small/medium,  =  medium/ small 

VI 

Response 

Time 

<10  sec. 

VII 

Operational 

Role 

Processes  basic  data 

Provides  fundamental  service 

VIII 

Dependence 

Async  hr ono  u  s ,  ind  ep  end  ent 
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2.2.4  Characteristics  of  Data  Base 

There  are  two  characteristics  which  may  be  used  to  describe 
the  NAS  data  base:  size  and  complexity.  Size  has  been  expressed 
as  small,  medium,  large  and  very  large,  using  the  same  limits  as 
for  amount  of  storage  required  for  functions  (Section  2. 2. 2.1): 

small  <  5,000  bytes, 

5,000  <  medium  <  20,000 
20,000  <  large  <  100,000 
100,000  <  very  large. 


Complexity  is  not  as  easy  to  deal  with  in  a  general  way.  In  this 
case,  however,  the  files  used  are  relatively  simple,  so  that 
their  structure  can  be  shown  directly. 

Each  data  base  is  considered  to  be  made  up  of  files,  each 
being  made  up  of  items,  and  each  item  (possibly)  made  up  of  sub- 
items.  The  complexity  of  the  data  bases  may  then  be  shown  by 
listing  the  files,  items,  and  sub-items  explicitly. 

In  Table  2.2-6,  the  major  elements  of  the  four  Baseline 
System  data  bases  are  listed:  Track  Data,  Flight  Data, 

Operational  and  Environmental  Data,  and  Display  Data.  An 
estimate  of  file  size  and  a  description  of  the  item  and  sub-item 
structure  are  given.  The  form  in  which  each  item  or  sub- item 
appears  is  given,  using  the  common  computer  programming 
terminology,  integer,  real,  logical,  or  alphanumeric.  An 
indication  of  the  functions  which  supply  and  use  each  item  is 
also  given. 

2.3  ARCHITECTURE  OF  THE  BASELINE  SYSTEM 

Once  the  operation  of  the  system  from  a  functional  viewpoint 
is  well  understood,  the  preliminary  design  of  the  computer  system 
may  go  forward.  During  the  design  process,  the  computer 
configuration  would  be  developed  in  conjunction  with  both  the 
allocation  of  functions  and  the  sizing  of  the  system.  In  this 
section,  however,  the  three  aspects  will  be  described  in  turn. 

2.3.1  Description  of  the  Configuration 

The  configuration  covered  in  this  report  was  earlier 
described  as  a  "distributed"  system,  with  processing  taking  place 
at  the  source  of  the  data  to  be  processed  or  at  the  location 
where  the  output  is  used.  A  configuration  of  that  type  designed 
to  carry  out  the  Baseline  Functions  is  shown  in  Figure  2.3-1. 


The  system  consists  of  a  set  of  independent  processors 
connected  to  each  other  by  an  Interprocessor  Communications 
Subsystem  (ICS)  whose  nature  is  not  disclosed  in  the  diagram. 

The  ICS  could  be  implemented  in  a  number  of  ways;  e.g.,  a  global, 
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TABLE  2.2-6  MAJOR  ELEMENTS  OF  BASELINE  DATA  BASES  (CONTINUED) 
DATA  BASE:  TRACK  DATA  II 
FILE  NAME:  TRACKS  (2)  FILE  SIZE: 


Correlation  and  FLAT) 

Display  DBM 
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MAJOR  ELEMENTS  OF  BASELINE  DATA  BASES  (CONTINUED) 
iASE:  FLIGHT  DATA- IV 

IAME:  AIRSPACE  ROUTE  FILE  SIZE:  LARGE 


TABLE  2.2-6  MAJOR  ELEMENTS  OF  BASELINE  DATA  BASES  (CONTINUED) 
DATA  BASE:  FLIGHT  DATA-V 

FILE  NAME:  BEACON  CODES  FILE  SIZE:  MEDIUM 

AIRCRAFT  CHARACTERISTICS 
AIR  CARRIERS 


Adaptation 


TABLE  2.2-6  MAJOR  ELEMENTS  OF  BASELINE  DATA  BASES  (CONTINUED) 
DATA  BASE:  TRACK  DATA — V 

FILE  NAME:  TRACK  CONTROL  FILE  SIZE:  SMALL 
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TABLE  2.2-6  MAJOR  ELEMENTS  OF  BASELINE  DATA  BASES  (CONTINUED) 
DATA  BASE:  flight  data— i 
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FIGURE  2.3-1  BASELINE  SYSTEM  HARDWARE  CONFIGURATION 


time-division-multiplexed  bus,  a  hierarchy  of  local  buses,  or  a 
switched  network  of  some  kind.  It  is  felt  that  this  aspect  of 
the  design  has  only  a  secondary  effect  on  the  performance  of  the 
system  as  a  whole;  therefore,  given  that  the  ICS  has  sufficient 
capacity  to  meet  the  demands  placed  on  it,  the  choice  of 
implementation  may  be  made  independently  of  the  rest  of  the 
system. 

The  "distributed"  Baseline  System  contains  nine  types  of 
processors,  as  shown  in  Figure  2.3-1.  There  is  one  Radar 
Processor  (R)  for  each  sensor  in  the  system.  Its  job  is  to 
accept  the  input  stream  of  radar  data  from  the  sensor  (DABS  or 
ATCRBS ) ,  process  the  data  where  necessary  and  route  it  to  the 
appropriate  sector  processor.  The  Bulk  Flight  Data  Processor 
(Fb)  reads  in  prestored  flight  plans  and  processes  them  for  later 
use,  the  Conflict  Processor  (C)  looks  for  conflicts  in  the  flight 
paths  of  aircraft  in  the  system  and  issues  warnings  when  they 
occur,  and  the  Display  Flight  Data  Processor  (F^)  distributes  the 
flight  data  to  the  sector  processors  as  it  is  needed. 

Each  sector  work-station  is  manned  by  two  controllers, 
preserving  the  current  R  and  D  positions.  The  sector  is  served 
by  three  processors  with  attendent  displays  and  data  entry 
devices.  The  R  controller  uses  displays  driven  by  the  R-position 
Display  Processor  (Dr)  which  receives  data  from  the  corresponding 
Tracking  Processor  (T).  The  D  controller’s  station  is  driven  by 
the  D-position  Display  Processor  (D^)  which  receives  data  from 
processor  F^.  There  are  as  many  work-stations  as  there  are 
sectors,  plus  a  few  spares  for  training,  maintenance,  and  backup. 

The  External  Interface  Processor  (Ie)  serves  as  a  message 
processor,  linking  the  Center  computer  to  the  DABS  data-link,  the 
Weather  Processing  system,  and  the  Flight  Service  Station  system. 
Finally,  the  Supervisory  Processor  (S)  exercises  control  over  the 
whole  system,  collects  critical  and  performance  measurement  data, 
and  initiates  startup,  restart,  and  start-over  procedures. 

Each  processor  has  sufficient  private  memory  to  hold  all  of 
its  programs  and  data,  including  appropriate  data  bases;  there  is 
no  global  memory.  Bulk  storage  devices  are  attached  to  the  Bulk 
Flight  Data  Processor,  Fb,  and  to  the  Supervisory  Processor,  S. 
The  latter  is  also  equipped  with  an  I/O  Terminal  for  operator 
interface. 

2.3.2  Allocation  of  Functions  and  Data  Bases 

The  functions  to  be  performed  and  the  data  bases  to  be  used 
by  the  Baseline  System  have  been  described  in  the  preceding 
section.  The  allocation  of  processing  functions  and  the 
associated  data  bases  to  processors  is  shown  in  Table  2.3-1  and 
2.3-2,  respectively.  The  rationale  for  allocating  functions  was 
based  on  the  following  considerations: 
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TABLE  2.3-1  ALLOCATION  OF  FUNCTIONS  IN  THE  BASELINE  SYSTEM 


PROCESSOR 

R 


F 


b 


C 


FUNCTION 


Radar  Data  Preliminary  Processing 
Real-time  Quality  Control* 

Dynamic  Simulation* 

Data  Routing 


Bulk  Store  Processing 
Flight  Plan  Activation 
Route  Conversion 

Flight  Plan  Position  Extrapolation 

Fix-Time  Calculation 

En  Route  Metering 

Flight  Plan  Probe 

Message  Routing 

Flight  Data  DBM 

0$E  Data  DBM 


Conflict  Alert 
Conflict  Resolution 
MS  AW 


Message  Routing 
0§E  Data  DBM 
Track  Data  DBM 


F 


d 


T 


S 


Beacon  Code  Allocation 
Fix-Time  Calculation 
Posting  Determination 
Message  Routing 
Flight  Data  DBM 


Display  Generation 
Display  Control 
Message  Processing 

Target/Track  Correlation 
Track  Acquisition 
Tracking  (FLAT  §  Free) 
Association  Checking 


Supervisory  Functions 
Message  Processing 
System  Performance  Data  DBM 
Critical  Data  DBM 


Message  Processing 


*Actually  running  in  only  one  or  a  small  number  of 
the  set  of  processors. 
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PROCESSOR 

DATA  BASE 

Fb 

Flight  Data 

0§E  Data 

C 

Track  Data 

0§E  Data 

Fd 

Flight  Data 

T 

Track  Data 

Dd’Dr 

Display  Data 

S 

System  Perform¬ 
ance  Data 

Critical  Data 

REMARKS 


Weather,  Airport 
Sensors,  MSAW,  Airport 


One  sector  per 
processor 

One  sector  per 
processor 


a)  The  independence  of  the  function  with  respect  to  other 
functions  and  to  data  bases  in  the  system, 

b)  The  nearness  of  the  function  in  terms  of  processing 
sequence  to  the  source  of  the  data  or  the  user  of  the 
processed  data, 

c)  The  place  of  the  function  in  the  expected  sequence  of 
operation . 

Since  the  configuration  to  be  studied  was  a  "distributed"  system, 
the  first  thought  in  each  case  was  to  assign  the  function  to  a 
separate  processor.  This  view  was  then  modified  as  necessary  to 
account  for  strong  functional  and  data  dependencies  and  to  ensure 
that  the  various  processing  sequences  required  of  the  system  were 
supported. 

There  is  no  simple,  direct  way  to  explain  how  the  system  is 
expected  to  operate.  The  account  which  follows  describes  in 
roughly  chronological  order  the  processing  which  takes  place  when 
an  aircraft  departs  from  a  terminal  in  the  Center’s  area  and  then 
the  processing  which  accompanies  an  arrival.  (This  could  be 
thought  of  as  the  same  aircraft  entering  the  adjacent  Center's 
area  and  arriving  at  a  terminal  there).  During  the  course  of  the 
description,  the  operation  of  various  functions  which  could  take 
place  are  described  in  terms  of  the  processing,  the  data 
accesses,  and  the  communications.  Not  every  flight  will  require 
all  of  the  processing  described,  but,  for  illustrative  purposes, 
as  many  features  as  possible  are  included. 

At  some  time,  say  30  minutes,  before  Flight  XY555  is 
scheduled  to  depart  from  terminal  TER  in  the  area  served  by  the 
Center  being  described,  the  prestored  flight  plan  is  read  from 
the  bulk  store  by  the  Bulk  Store  Processing  function  operating  in 
the  Bulk  Flight  Data  Processor,  Fb»  Within  the  next  few  minutes, 
the  flight  plan  is  activated  by  Flight  Plan  Activation  and  the 
route  is  converted  to  the  standard  internal  form  by  Route 
Conversion.  This  information  is  stored  in  the  Flight  Data  Data 
Base  by  the  Flight  Data  Data  Base  Management  function,  and,  at 
the  same  time,  a  copy  is  sent  to  the  Display  Flight  Data 
Processor  (Fd)  to  be  stored  in  its  Flight  Data  Data  Base  by  its 
Flight  Data  Data  Base  Management  function.  At  this  point,  the 
information  stored  in  the  two  data  bases  is  the  same,  but,  as  the 
flight  advances  through  the  ATC  system,  the  different  functions 
in  the  two  Flight  Data  processors  will  develop  different  data. 
Care  will  have  to  be  taken  to  insure  that  the  two  data  bases 
remain  consistent  and  synchronized  with  each  other. 

In  Fd/  the  Posting  Determination  function  prepares  to 
transmit  to  the  Terminal  and  to  the  en  route  sector  containing 
the  departure  fix,  flight  data  concerning  XY555  and  its  time  of 
departure.  At  an  approximate  time,  say  ten  minutes  prior  to 
departure,  the  information  is  posted.  That  is,  Fd  transmits  a 
message  to  the  terminal  via  the  ICS  and  the  External  Interface 


Processor,  Ie,  and,  at  the  same  time,  selects  the  proper  D- 
position  Display  Processor,  Dd,  to  which  to  post  the  departure. 

Eventually,  Flight  XY555  departs  TER  and  becomes  visible  to 
a  sensor  connected  to  the  Center.  Target  returns  are  received  by 
the  corresponding  Radar  Processor,  R,  and  are  subjected  to 
Preliminary  Processing  and  routed  to  the  appropriate  Tracking 
Processor,  T,  (obviously,  the  one  servicing  the  sector  where  the 
departure  fix  is  located).  The  data  may  be  sent  to  one  or  more 
other  sectors  if  the  aircraft  is  near  a  boundary.  Each  Tracking 
Processor  will  do  Target/Track  Correlation,  Track  Acquisition  and 
Tracking  (FLAT  and  Free)  for  tracks  and  targets  within  its  sector 
and  will  transmit  data  to  the  R-position  Display  Processor,  Dr, 
for  output  to  the  controller  on  the  usual  Plan  View  Display 
( PVD ) .  In  the  case  of  Flight  XY555,  position  and  velocity  data, 
cross-tell  data,  is  sent  from  the  Terminal  to  the  Center  for  some 
time  prior  to  handoff  of  control  so  that  the  Center  can  be  sure 
it  is  acquiring  the  correct  target.  This  data  is  received  at  the 
External  Interface  Processor  and  routed  by  prior  arrangement  to 
the  correct  T  processor;  i.e.,  to  the  correct  sector. 

Note  that  two  different  data-routing  situations  have  been 
described:  radar  data  from  sensors  being  routed  to  appropriate 
sectors  and  cross-tell  data  from  an  adjoining  facility  being 
routed  to  an  approximate  sector.  In  the  first  case,  a  mapping  is 
required  from  one  position  of  the  center  area  -  the  coverage  by 
the  sensors  -  to  another  -  the  set  of  sectors.  This  should  be  a 
simple,  but  non-trivial,  task  for  the  Radar  Processors.  In  the 
second  case,  what  is  needed  is  merely  a  knowledge  of  which 
sectors  correspond  to  the  handoff  fixes  being  approached  by  the 
aircraft  in  question.  The  trivial  matching  process  will  not 
extend  the  External  Interface  Processor. 

The  flight  will  pass  through  sector  after  sector,  being 
handed  off  from  one  to  the  next  at  the  appropriate  hand-off 
fixes,  being  preceded  by  postings  along  the  way.  As  the  flight 
approaches  the  exit  fix  from  the  center  area,  its  flight  plan  is 
passed  to  the  adjacent  center,  then  the  cross-tell  data  and  then 
control  itself,  through  the  hand-off  message.  The  responsibility 
for  the  flight  plan  passing  is  given  to  F<j  and  for  the  cross-tell 
and  hand-off  is  given  to  T. 

On  the  arriving  side  of  this  transfer,  the  Ie  processor 
receives  the  flight  plan,  which  it  passes  to  Ffc>,  and  the  cross- 
tell  and  handoff  messages,  which  is  passes  to  T.  The  flight  plan 
is  activated,  and  its  route  converted  to  standard  form  in  F^; 
this  information  is  then  stored  in  the  Flight  Data  Base  and  also 
passed  to  processor  F^ ,  in  the  same  way  as  pre-filed  flight 
plans,  described  above,  are  passed.  While  the  flight  is  being 
tracked  across  each  sector  in  the  T  processors  and  being  passed 
from  one  sector  to  the  next,  the  Flight  Plan  Position 
Extrapolation  and  En  Route  Metering  functions  in  the  Fu,  processor 
monitor  its  progress.  The  Position  Extrapolation  function  sends 
position  updates  for  each  flight  to  the  T  processors  for  use  by 


1 

the  Association  Checking  and  Flight  Plan  Aided  Tracking  j 

functions;  the  En  Route  Metering  function  sends  advisories  and  i 

commands  to  the  Fd  processor  for  conveyance  to  the  appropriate  Dd  j 

processor .  1 

Note  that  in  this  implementation,  flight  plan  data  displayed  j 

through  the  Dd  processor,  principally  as  flight  postings,  come  j 

from  the  Fd  processor  for  the  most  part,  while  flight  plan  data  j 

used  in  the  T  processor  or  displayed  through  the  Dr  processor  j 

come  from  the  Fb  processor.  Clearly  there  is  a  need  for  careful 
design  at  this  point  so  that  contradictory  information  can  never 
appear  in  the  D-  and  R-  position  displays. 

The  T  processors  send  tracking  information  to  the  Conflict, 
or  C,  processor  which  maintains  a  Track  Data  Data  Base  for  all 
tracks  in  the  system  and  is  responsible  for  the  Conflict  Alert 
and  Conflict  Resolution  functions  which  transcend  sector 
boundaries.  The  related  MSAW  function  is  also  assigned  to  the  C 
processor.  Warnings  and  commands  (or  recommendations)  are 
transmitted  to  the  Fd  processor  for  retransmission  to  the 
appropriate  Dj  processor  and  subsequent  display  to  the 
controller.  They  are  also  sent  to  the  Ie  processor  when  DABS 
data  link  or  interfacility  communication  is  indicated.  It  is 
assumed  that  controller  approval  is  required  for  transmission 
from  the  center;  these  approvals  (or  disapprovals)  are  routed 
from  the  Dd  processor  to  both  the  C  and  Ie  processors. 

The  controller,  or  sector,  work-station  consists  of  two 
displays  and  related  data-entry  devices,  driven  by  the  Dd  and  Dr 
processors.  The  station  is  self-contained  in  that  it  can,  once 
it  has  been  loaded  with  a  set  of  data,  operate  without  reference 
to  the  rest  of  the  system.  The  controller  can  modify  the  display 
and  enter  queries  and  commands  to  the  system  through  the  display 
processors.  Data  used  to  generate  displays  are  passed  to  Dr  from 
the  corresponding  T  processor  and  to  Dd  from  Fd- 

The  principal  avenue  for  requests  for  data  from  the  various 
data  bases  in  the  system  is  through  the  Dd  processor,  where  the 
requests  are  formatted  and  then  transmitted  to  the  Fd  processor. 

These  requests  which  can  be  satisfied  from  the  data  bases  in  Fd 
will  be  answered;  the  rest  will  be  forwarded  to  the  appropriate 
processor.  A  Flight  Plan  Probe  request  or  a  request  for  weather 
information  would  be  sent  to  Fb;  a  request  for  information  about 
a  conflict  situation  would  be  sent  to  the  C  processor. 

The  radar  input  processor,  R,  will  be  assigned  two  other 
functions:  Real-Time  Quality  and  Dynamic  Simulation.  The  former 
need  be  actually  running  in  only  one  of  the  R  processors  at  any 
time,  although  each  will  have  the  capability  if  assigned  the  task 
for  backup  purposes.  Dynamic  Simulation  can  be  run  on  one  R 
processor  for  each  training  sector  in  use. 

All  of  the  processors  will  collect  critical  and  system 
performance  data  and  send  them  to  the  S  processor  for  storage. 
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The  S  processor  will  use  the  critical  data  to  restart  the  system 
in  case  of  a  failure,  or  part  of  the  system  in  case  of  a  partial 
failure. 

2.3.3  System  Sizing 

It  must  be  assumed  that  the  Baseline  System  will  be  capable 
of  carrying  out  all  of  the  functions  of  the  ATC  system  at  the 
traffic  levels  expected  in  the  baseline  year,  1985.  These 
traffic  levels  have  been  discussed  in  Section  2.1.4,  and  factors 
germane  to  the  operation  of  the  system  have  been  derived  and 
listed  in  Table  2.1-1.  The  operational  characteristics  of  each 
of  the  functions  of  the  Baseline  are  given  in  Table  2.2-5,  and 
the  evaluation  of  these  characteristics,  with  the  appropriate 
load  factors,  gives  a  measure  of  the  system  size. 

Two  assumptions  underline  many  of  the  processing  estimates. 
The  first  is  that  sectors  are  sized  and  configured  so  that  each 
one  handles  approximately  the  same  traffic  load.  The  second  is 
that  all  of  the  targets  in  a  sector  may  be  scanned  by  the  sensors 
in  one  second.  Since  there  is  a  response  time  requirement  on  all 
target  and  track  related  processing,  all  such  processing  may  be 
required  to  take  place  in  that  second  rather  than  spread  over  the 
whole  scan  time. 

To  illustrate  the  analysis  that  has  been  carried  out,  the 
operations  of  two  functions  are  described  below  in  detail. 

2. 3. 3.1  Analysis  of  Fix-Time  Calculation  -  This  is  a  routine 
which  is  called,  in  the  Fb  processor,  by  the  Flight  Plan  Position 
Extrapolation  and  Route  Conversion  functions  and,  in  the  Fd 
processor,  by  the  Posting  Determination  function.  According  to 
Table  2.2-5,  the  amount  of  processing  for  each  operation  of  the 
program  is  given  by: 


where  K,  ■  medium.  An  estimate  of  the  average  amount  of 
processing  per  second  in  the  Fb  processor  is  then 

p  =  —  +  _Ji_± — “)  k 

s  300  3600  '  M 

where  <J>A  *  number  of  active  flight  plans  in  the  system, 

$H  ■  number  of  flight  plans  activated  per  hour,  and 

»  number  of  flight  plan  amendments  per  hour. 

The  coefficient  gives  the  number  of  times  per  second  the  function 
is  called:  once  each  five  minutes  (300  seconds)  for  each  active 
flight  plan  by  Flight  Plan  Position  Extrapolation  and  once  for 
each  flight  plan  activated  or  flight  plan  amendment  entered. 
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The  values  of  4>a,  and  «h  for  the  small,  medium,  and  large 
centers  taken  from  Table  2.1-1  are: 


*H 


Smal  1 

Medium 

Large 

430 

668 

984 

254 

434 

728 

2,040 

2,160 

2,580 

values 

of  Ps  are  2.07 

Km,  2.95  Km,  1 

the  small,  medium,  and  large  centers,  respectively. 


'■M 


In  a  similar  way,  in  the  processor,  the  amount  of 
processing  is  given  by: 


41 


P  =  ( 
s  v  300 


A  +  H 


3600 


M 


resulting  in  values  of  1.50  Km,  2.35  Km  and  3.48  Km- 


2. 3. 3. 2  Analysis  of  Target/Track  Correlation  -  This  function 
operates  in  the  T  processor,  handling  the  target  data  transmitted 
from  the  radar  processor  and  the  tracks  assigned  to  the 
particular  sector.  The  average  processing  per  second  is: 


P  =  K  + 
S  s 


K 


+  K 


log„  T, 


where  p  ■  number  of  radar  targets  per  sector, 

?s  ■  number  of  tracks  per  sector. 

Using  the  numbers  from  Table  2.2-1,  the  processing  per  second  for 

small,  medium,  and  large  centers  is  27.65K  ,  50.05K  ,  and 

68.30K  ,  respectively.  s 

s 

2. 3. 3. 3  Comparative  Processing  Loads  -  It  is  desirable  to  have  a 
single  number  as  a  measure  of  processing  load  on  each  processor, 
and,  for  the  purposes  of  this  study,  that  number  need  have  no 
absolute  interpretation.  Such  a  number  which  is  here  called  the 
Comparative  Processing  Number  (CPN),  can  be  derived  for  each 
processor  in  the  system  by  summing  the  expressions  for  amounts  of 
processing  in  each  processor  and  then  applying  the  relation. 


100  Kg  «  10Km  =  Kl  =  1.  (Section  2. 2. 2. 2) 

As  an  example,  the  evaluation  of  the  processing  expressions  for 
the  C  processor  is  given  in  Table  2.3-3.  This  evaluation  for 
each  of  the  processors  results  in  the  set  of  Comparative 
Processing  Numbers  for  the  Baseline  System  processors  for  small, 
medium,  and  large  centers  given  in  Table  2.3-4. 


2. 3. 3. 4  Comparative  Communications  Requirements  -  The 
communications  among  the  functions,  and  hence  among  the 
processors,  is  the  next  matter  of  concern.  Given  the  allocation 


rASLE  2.3-3  EVALUATION  OF  PROCESSING  -  C  PROCESSOR 


FUNCTION 

PROCESSING 

SMALL 

MEDIUM 

LARGE 

Conflict  Alert 

0.02k'  +33. 82K 

S  M 

0 . 02k  +57 . 63k 

S  M 

0 . 02K  +90 . 51K 

S  M 

Conflict  Resolution 

0.02K  +0.016K. 

S  L 

0.02K  +0.040K. 

S  L 

0.02K  +0.093K. 

S  L 

MSAW 

0.03K  +8. 47k' 

S  M 

0.03K  +13 . 33KW 

S  M 

0.03KS+19.67KL 

Message  Routing 

0.02K 

o 

0.04KS 

0.10kg 

Track  Data  DBM 

50.80K 

J 

80 . 00Kg 

118. 00K 

J 

05E  Data  DBM 

25. 48K 

S 

36 . 2  3Kg 

54.20Kg 

Sum 

( 7  6 . 3  7  k's 
+42. 29k 
+  0 . 0 16K L) 

(116. 34Kg 
+70.96Km 
+  0.040Kl1 

(172.37kg 
+110.18Km 
+0.093K  ) 

L 

Comparative  Pro¬ 
cessing  Number 

5.01 

8.30 

12.83 

TABLE  2.3-4  COMPARATIVE  PROCESSING  NUMBERS  -  BASELINE  SYSTEM 


PROCESSOR 

CPN 

REMARKS 

Small 

Medium 

R  (ATCRBS) 

1.22 

3.02 

4.31 

R  (DABS) 

1.02 

2.82 

4.12 

Fb 

1.38 

2.16 

3.28 

C 

5.01 

8.30 

12.83 

Fd 

0.47 

0.73 

1.10 

Dd 

0.07 

0.08 

0.09 

T 

7.33 

11.57 

14.77 

Dr 

2.22 

2.82 

3.32 

Xe 

1.70 

2.50 

3.60 

S 

4.83 

5.05 

5.84 

i 


of  functions  to  the  processors,  the  traffic  and  other  load 
factors,  it  is  possible  to  estimate  the  number  of  messages 
generated  in  the  processors  and  their  lengths,  and  thus  to 
calculate  the  average  communications  traffic  into  and  out  of  each 
processor . 

As  an  example,  consider  the  message  traffic  occur ing  as  the 
result  of  the  discovery  by  the  Conflict  Alert  function  of  an 
impending  problem  and  the  generation  of  commands  to  the  aircraft 
involved  by  the  Conflict  Resolution  function.  The  message  flow 
is  illustrated  in  Figure  2.3-2.  The  C  processor  sends  the 
advisory/command  message  simultaneously  to  T  processor  for  relay 
to  Dr ;  to  the  Ffj  processor  for  relay  to  D^;  and  to  Ie  for  data- 
link  if  the  aircraft  are  equipped,  and  for  inter-facility  if  the 
conflict  is  near  the  center  boundary.  The  D-controller  approves 
or  disapproves  the  commands,  thereby  generating  a  message  to  F^ 
which  will  be  relayed  to  Ie,  to  initiate  transmission  of  the 
Advisory  Command  message,  and  to  C,  for  action  by  the  Conflict 
functions.  All  of  these  message  transactions  and  the  others  like 
them  have  been  counted  and  tabulated;  their  frequencies  and 
lengths  estimated. 

In  calculating  the  required  channel  capacities  into  and  out 
of  each  processor,  it  was  assumed  that  message  lengths  would  be 
doubled  by  the  redundancy  needed  for  error  detection  and 
correction,  and  that  the  capacity  provided  should  be  three  times 
the  required  average  to  account  for  peaks  in  the  demand.  It  was 
found  on  examination  of  the  data  that  the  communications 
requirements  seemed  to  clump  together  in  three  ranges. 

Therefore,  three  types  of  channel  were  postulatd  to  cover  these 
ranges.  The  slow  speed  channel,  called  Type  A,  has  a  capacity  of 
9,600  bits  per  second.  The  medium  speed,  Type  B,  has  a  capacity 
of  33,600  bits  per  second,  and  the  high  speed,  Type  C,  has  a 
capacity  of  300,000  bits  per  second.  The  channel  types  into  and 
out  of  each  processor  for  the  small,  medium,  and  large  centers 
are  given  in  Table  2.3-5. 

The  requirements  for  redistribution  of  critical  data  in  the 
event  of  a  restart  are  given  parenthetically  in  the  table.  These 
requirements  were  calculated  by  assuming  that  all  such  data  is 
transmitted  over  a  period  of  four  seconds.  For  instance,  in  the 
T  processor,  it  was  assumed  that  36  bytes  were  recorded  for  each 
track  during  each  scan.  This  amounts  to  27,  40,  and  50 
bytes/second  for  the  small,  medium,  and  large  centers, 
respectively.  On  restart,  data  for  a  whole  10  second  scan  will 
have  to  be  transmitted  over  a  four  second  interval,  giving  68, 

100  and  125  bytes/second.  These  values  are  multiplied  by  16  to 
get  the  bit  rates,  including  redundancy  of  1,100,  1,600,  and 
2,000  bits/second.  Note  that  this  is  a  peak  rate  requirement, 
which  can  be  satisfied  in  each  case  by  a  slow  speed,  or  Type  A, 
channel . 
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FIGURE  2.3-2.  MESSAGE  TRAFFIC  RESULTING  FROM 
DETECTION  OF  A  CONFLICT 
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TABLE  2.3-5  COMMUNICATIONS  CHANNEL  REQUIREMENTS  -  BASELINE  SYSTEM 


PROCESSOR  _ COMMUNICATIONS  CHANNEL  TYPE 


SMALL 

MEDIl 

JM 

LARGE 

IN 

OUT 

IN 

OUT 

IN 

OUT 

R(ATCRBS) 

A 

(A)* 

B 

A 

(A) 

B 

A 

(A) 

C 

R(DABS) 

A 

(A) 

B 

A 

(A) 

B 

A 

(A) 

C 

Fb 

A 

(C) 

B 

A 

(C) 

C 

A 

(O 

C 

C 

C 

(B) 

B 

C 

(B) 

B 

C 

(B) 

B 

Fd 

A 

(C) 

B 

B 

(O 

C 

B 

(C) 

C 

Dd 

A 

(A) 

A 

A 

(A) 

A 

A 

(A) 

A 

T 

B 

(A) 

B 

B 

(A) 

c 

B 

(A) 

C 

Ur 

A 

(A) 

A 

A 

(A) 

A 

A 

(A) 

A 

le 

B 

(A) 

B 

B 

(A) 

B 

B 

(A) 

B 

S 

2C 

A  (2C) 

3C 

A  (3C) 

3C 

A  ( 3C) 

*Figures  in  parentheses  are  for  redistribution  of  critical 
data  for  restart. 


Type  A  capacity 
Type  B  capacity 
Type  C  capacity 


9,600  bits  per  second 
33,600  bits  per  second 
300,000  bits  per  second 
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3.  THE  FUTURE  SYSTEM 

3.1  ENVIRONMENT  OF  THE  FUTURE  SYSTEM 

The  Future  System  is  a  hypothetical  ATC  Central  Computer 
Complex  for  1995  that  might  evolve  from  the  "Baseline"  System  of 
1985-1995.  It  is  assumed  that  the  "Future"  System  is,  in  effect, 
the  "Baseline"  System  modified  and  enhanced  to  meet  functional 
requirements  beyond  1995. 

3.1.1  Surveillance 


By  1995,  surveillance  will  be  based  wholly  on  the  DABS 
network  rather  than  the  mixed  DABS-ATCRBS  system  that  prevailed 
during  the  lifetime  of  the  supplanted  "Baseline"  System.  All 
aircraft  are  assumed  to  be  equipped  with  DABS  transponders; 
additionally,  those  aircraft  utilizing  Level  1  service  will  be 
suitably  equipped  for  DABS  data  link.  Each  ATC  facility's 
computer  complex  will  be  connected  to  the  DABS  network,  thus 
assuring  coverage  continuity.  Target/track  correlation  and,  in 
fact,  automatic  tracking  will  no  longer  be  required  functions  at 
the  facility  computer  because  of  the  uniqueness  of  DABS  target  ID 
and  position  data. 

3.1.2  Communications 


It  is  assumed  that  ground  based  interfacility  and  remote 
communications  will  continue  to  be  provided  by  the  NADIN  system 
with  its  common  interface  standard  and  communications,  protocol . 
The  principal  medium  for  ground/air  communications  will  be  the 
DABS  data  link. 

3.1.3  Interfaces 


The  "Future"  System's  interfaces  with  other  facilities  are 
assumed  to  be  substantially  the  same  as  those  previously 
described  for  the  "Baseline"  System;  i.e.,  the  Central  Flow 
Control  Facility,  Weather  Services  Facility,  Flight  Service 
Facility,  and  adjacent  ATC  facilities. 

3.1.4  Air  Activity 

The  1995  traffic  forecast  was  estimated  in  a  manner  similar 
to  that  of  1985,  which  is  described  in  Appendix  B. 

The  parameters  describing  the  en  route  system  in  1995,  as 
well  as  the  values  assumed  to  be  reasonable  for  the  small, 
medium,  and  large  centers  (projected  data  from  three  actual 
centers,  Denver,  Memphis  and  Chicago),  are  presented  in  Table 
3.1-1. 
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TABLE  3.1-1  PARAMETERS  DESCRIBING  ATC  OPERATIOh 

CENTER 

NO.  PARAMETER  SMALL  MEDIUM 


Number  of  Radar  Targets 
From  the  Sensors 

Number  of  Sensors 

Number  of  Tracks  in  the 
System  (Peak) 

En  Route,  Level  1 
En  Route,  Level  2 
Terminal 

Number  of  Correlated  Targets 

Number  of  Flight  Plans  Entered 
from  Bulk  Store  (Busy  Hour) 

Number  of  Flight  Plans  Entered 
in  Two  Minute  Intervals  from 
Bulk  Store 

Number  of  Flight  Plans  Entered 
Through  FSSs  (Busy  Hour) 

Number  of  Active  Plight  Plans 
in  the  System  (Peak) 

Number  of  Displays  (Sectors) 

En  Route,  Level  1 
En  Route,  Level  2 
Terminal 

Number  of  R-controllcr  Opera¬ 
tions  (Per  Minute  Per 
Posit  ion) 

En  Route,  Level  1 
En  Route,  Level  2 
Terminal 

Number  of  Uncorrelated 
Radar  Returns  (Peak) 

Number  of  Conflicts 
Predicted  per  Hour 

Number  of  Departures/ 

Arrivals  (Busy  Hour) 

Number  of  Overflights 
(Busy  Hour) 

Number  of  P-controllcr 
Operations  (Per  Minute 
Per  Position) 

Fn  Route,  Level  1 
Fn  Route,  Level  2 
Terminal 

Number  of  MSAW  Conflicts 
Detected  per  Hour 

Number  of  Flight  Plan  Amend¬ 
ments  Entered  per  Hour 

Number  of  El  ight  Plans 
Activated  per  Hour 

Number  of  El  ight  Plan 
Entries  per  Display 

En  Route 
Tern ina 1 


Not  Applicable 
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3.1.5  Airspace  Structure 

In  1995,  airspace  structure  will  be  such  that  positive 
control  will  be  exercised  where  traffic  is  heavy,  while  maximum 
freedom  will  be  allowed  where  traffic  is  light.  The  assumed 
structure  provides  for  several  levels  of  service  in  essentially 
four  categories  of  airspace;  the  levels  of  service  range  from 
highly  automated,  central  ground-controlled  separation  in 
positive  control  airspace  to  ground-independent,  air-derived 
separation  in  uncontrolled  airspace.  It  is  assumed  that  the 
traffic  in  each  center  area  is  distributed  so  that  43%  is  under 
Level  1  control,  19%  under  Level  2  control,  and  38%  not  under 
positive  control.  The  airspace  structure  and  levels  of  service 
are  depicted  in  Figure  3.1-1. 

3.1.6  Future  System  Functions 

The  set  of  functions  performed  by  the  Future  System  will 
include  most  of  those  performed  by  the  Baseline  System  plus  three 
new  functions: 

Coordinate  Conversion, 

Clearance  Generation,  and 

Terminal  Path  Control. 

Table  3.1-2  contains  a  list  of  Baseline  functions  indicating 
those  carried  over  and  added  to  the  new  functions  of  the  Future 
System. 

ATC  service  provided  in  Level  2  (see  Figure  3.1-1)  will  be 
based  primarily  on  the  following  functions: 

MSAW, 

Conflict  Detection  and  Resolution,  and 
En  Route  Metering. 

Each  of  these  functions  generates  warnings,  commands,  or 
advisories  which  are  voice-linked  or  data-linked  to  aircraft, 

(but  only  if  approved  by  the  air  traffic  controller),  in  what 
might  be  characterized  as  a  semi-automatic  mode  similar  to  the 
present  ATC  system. 

Of  the  three  new  functions,  only  Clearance  Generation  is  a 
Level  1  function.  Coordinate  Conversion  is  an  internal  function 
and  Terminal  Path  Control,  a  terminal  service  function.  Unlike 
the  warnings,  commands,  and  advisories  from  the  Level  2  service 
functions,  the  messages  from  Clearance  Generation  are 
automatically  data-linked  to  aircraft  in  the  Level  1  service 
area.  Since  conflict-free  flight  paths  are  assured  by  Clearance 
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TABLE  3.1-2.  COMPARISON  OF  BASELINE  AND  FUTURE  SYSTEM  FUNCTIONS 


BASELINE  SYSTEM 


Bulk  Store  Processing 


Flight  Plan  Activation 


Route  Converstion 


Posting  Determination 


Flight  Plan  Position 
Extrapolation 


Fix-Time  Calculation 


Flight  Plan  Probe 


FUTURE  SYSTEM 


Bulk  Store  Processing 


Flight  Plan  Activation 


Route  Converstion 


Posting  Determination 


Flight  Plan  Position 
Extrapolation 


Fix-Time  Calculation 


Flight  Plan  Probe 


COMMENTS 


Dynamic  Simulation 


Critical  Data  Recording 


Supervisory  Function 


Display  Generation 


DispLay  Control 


Enroute  Metering 


Conflict  Alert 


Conflict  Resolution 


Association  Checking 


Beacon  Code  Allocation 


Radar  Data  Preliminary 
Processing 


Real-Time  Quality  Control 
of  Radar  Data 


Target-Track  Correlation 


Track  Acquisition 


Tracking  (FLAT  and  Free) 


Dynamic  Simulation 


Critical  Data  Recording 


Supervisory  Function 


Display  Generation 


Display  Control 


En  Route  Metering 


Conflict  Detection 
and  Resolution 


Augmented  in  Future  System 


Modified  and  Combined  in 
Future  System 


These  functions  are  not 
included  in  the  Future 
System  because  of  the 
radar  processing  and 
tracking  performed  by 
DABS. 


Coordinate  Conversion  _ 


Clearance  Generation  (AERA 


Terminal  Path  Control 


New  Function 


New  Function 


Generation,  the  clearances  are  automatically  dispatched  unless 
disapproved  by  the  air  traffic  controller. 

3.2  FUNCTIONAL  DESCRIPTION  OF  THE  FUTURE  SYSTEM 

The  functional  description  of  the  Future  System  reveals  both 
its  similarities  with  and  differences  from  the  Baseline  System. 

In  the  case  of  the  Baseline  System  the  description  is 
implementation-independent,  showing  neither  hardware  nor 
operating  system  dependencies. 

3.2.1  Functional  Organization  of  the  Future  System 

The  functional  organization  of  the  Future  System  is 
illustratd  in  a  block  diagram.  Figure  3.2-1,  and  its  processing 
functions  described  in  Tables  3.2-1  through  3.2-4.  The  principal 
differences  between  the  Baseline  and  Future  Systems  as  detailed 
in  Figure  3.2-1  are  attributable  to: 

a)  All  radar  processing  and  tracking  functions  being 
performed  by  processors  at  DABS  sensor  sites, 

b)  Incorporation  of  Terminal  Approach/Control 
functions  at  the  en  route  facility,  and 

c)  Introduction  of  a  Clearance  Generation 
function  similar  to,  and  possibly  derived 
from,  the  Automatic  En  Route  ATC  (AERA)  concept. 

As  a  result  of  (a)  above,  the  unique  target  ID  and  position 
data  received  from  the  DABS  network  need  only  be  subjected  to  a 
coordinate  conversion  process  which  transforms  DABS  sensor  site 
coordinates  to  the  en  route  system's  stereographic  plane.  The 
converted  target  data  is  then  sent  to  the  Track  Data  Base 
Management  System  for  subsequent  distribution  to  other  functions 
requiring  track  data.  Note  that  there  are  no  tracking  functions 
in  the  Future  System  because  they  would  be  unnecessarily 
redundant.  In  fact,  even  if  a  DABS  site  should  fail,  another 
site  or  sites  in  the  DABS  network  would  provide  the  required 
data. 

The  integration  of  terminal  Approach/Control  functions  in 
the  en  route  center  is  provided  by  a  new  function  shown  in  the 
block  diagram  as  Terminal  Path  Control.  The  latter  generates 
approach/departure  profiles  and  the  metering  and  spacing  commands 
that  are  automatically  dispatched  to  the  aircraft  via  the  DABS 
data  link  unless  the  terminal  controllers  intervene  and  override 
the  messages. 

The  introduction  of  the  Clearance  Generation  function 
assures  that  aircraft  receiving  Level  1  service  are  provided 
conflict-free  flight  paths  through  the  continous  monitoring  of 
all  aircraft  in  the  airspace  and  the  automatic  generation  of 
essential  clearances  for  transmission  via  DABS  data  link. 


3.2.2  Characteristics  of  Functions 


The  set  of  characteristics  with  which  the  functions  can  be 
described  is  unchanged  from  those  discussed  in  Section  2.2.2. 

The  operational  characteristics  of  the  new  functions,  as  well  as 
those  Baseline  System  functions  which  will  be  modified,  are 
described  in  Table  3.2-5.  To  avoid  duplication,  the  retained 
Baseline  System  functions  which  remain  unchanged  are  not  included 
in  Table  3.2-5. 

3.2.3  Characteristics  of  Data  Bases 

The  data  bases  in  the  Future  System  are  essentially  the  same 
as  those  of  the  Baseline  System  as  described  in  Section  2.2.4  and 
Table  2.2-6,  and  are,  therefore,  not  repeated  herein. 

3.3  ARCHITECTURE  OF  THE  FUTURE  SYSTEM 

The  "Future"  System  is  derived  from  the  "Baseline"  System  by 
the  addition  (or  deletion)  of  resources  processors,  memories, 
displays,  etc.  The  choice  of  what  to  add  or  delete  is  made  on 
the  basis  of  functional  or  capacity  requirement  as  in  the 
Baseline  System.  The  following  sections  will  describe  the 
configuration  which  resulted  from  this  design  process  as  well  as 
the  functional  allocations  and  sizing  that  led  to. the 
configuration. 

3.3.1  Description  of  the  Configuration 

The  configuration  of  the  Future  System  is  shown  in  Figure 
3.3-1.  As  in  the  Baseline  System,  the  Inter-processor 
Communications  Subsystem  connects  those  processors  which  have 
need  to  exchange  messages.  The  configuration  is  made  up  of 
eleven  types  of  processors,  each  of  which  has  its  own  memory. 

Two  new  processors,  the  Clearance  Generation  Processor,  Fc  and 
the  Terminal  Processor,  Tp  ,  have  been  added,  and  all  but  one  of 
the  Radar  Processors,  R,  nave  been  deleted.  The  only  other 
obvious  difference  is  the  addition  of  a  DABS  input  to  External 
Interface  Processor  Ie. 

3.3.2  Allocations  of  Functional  and  Data  Bases 

The  allocation  of  the  functions  to  the  processors  is  given 
in  Table  3.3-1  and  of  data  bases  to  processors  in  Table  3.3-2. 
Functions,  data  bases,  and  processors  that  are  new,  or 
drastically  changed,  are  marked  with  an  asterisk. 

As  shown  in  Figure  3.3-1,  the  Future  System  consists  of  ten 
types  of  processors,  each  having  its  own  memory  for  programs  and 
data  rather  than  global  memory.  Bulk  or  secondary  storage  is 
attached  to  the  Bulk  Flight  Data  Processor  Fb  and  the  Supervisory 
Processor,  S.  Unlike  the  Baseline  System  which  has  a  Radar 
Processor,  R,  directly  connected  to  each  ATCRBS/DABS  Sensor,  the 
Future  System  has  only  one  Radar  Processor  with  no  direct 
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Routes  and  Fixes  I  Flight  Data  D.B 


TABLE  3.2-5  OPERATIONAL  CHARACTERISTICS  OF  FUTURE  FUNCTIONS 


EN  ROUTE  METERING 

Operates  on  each  Level  2  flight  at  prescribed  fixes 
and/or  times 

I 

Storage 

Medium 

II 

Process ing 
per  Operation 

P  =  K! 

where  =  medium 

III 

Frequency 
of  Operation 

Aperiodic,  ~once/five  minutes  for  each  Level  2  flight 

IV 

Types  of 
Processing 

I/O  0  Char.  10% 

Calc.  40%  Match.  0 

Log.  50% 

V 

Amount  of 

Data 

In:  D  =  Kl  Out:  D  =  K2 

where  =  medium  =  medium 

VI 

Respon  se 

T  ime 

<10  seconds 

VII 

Operational 

Role 

Produces  traffic  management  directives  for  use  by  controller 

VIII 

Dependence 

Depends  on  properly  processed  Flight  Data 
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TABLE  3.2-5  OPERATIONAL  CHARACTERISTICS  OF  FUTURE  FUNCTIONS 

(CONTINUED) 


k 


CONFLICT  DETECTION  AND  RESOLUTION 

Processes  all  Level  2  tracks  periodically 

I 

Storage 

Medium 

II 

Process ing 
per  Operation 

P  =  Kx  +  K2  T  log  T  +  K3  C 

where  T  =  number  of  Level  2  tracks,  C  =  number  of  conflicts 
detected 

K1  =  small,  K?  *  medium,  =  large 

III 

Frequency 
of  Operation 

Periodic,  'v  once/minute 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  40%  Match.  35% 

Log.  25% 

V 

Amount  of 

Data 

In:  D  =  Kx  T  Out:  D  =  K2  C 

where  T  =  number  of  tracks,  C  =  number  of  conflicts  detected 
=  medium,  K2  ■  medium 

VI 

Respon  se 

Time 

<  10  seconds 

VII 

Operational 

Role 

Produces  traffic  control  commands  under  emergency  conditions 

VIII 

Dependence 

Uses  tracking  data  from  DABS 

TABLE 


3.2-5  OPERATIONAL  CHARACTERISTICS  OF  FUTURE  FUNCTIONS 

(CONTINUED) 


COORDINATE  CONVERSION 

Operates  once  per  buffer  load  per  sensor 

I 

Storage 

Medium  (including  buffer  space  in  and  out) 

II 

Processing 
per  Operation 

P  ;  T,  where  T  is  the  number  of  tracks 

=>  small,  =  small 

III 

Frequency 
of  Operation 

'v  once/second/sensor 

IV 

Types  of 
Processing 

I/O  20%  Char.  0 

Calc.  70%  Match.  0 

Log.  40% 

V 

Amount  of 

Data 

In:  D  =  Kx  +  K2  T  Out:  D  =  +  K2  T 

*  small,  K2  *  medium  Kj  *  small,  K2  =  medium 

VI 

Response 

Time 

<1  second 

VII 

Operational 

Role 

Processes  primary  input 

VIII 

Dependence 

Independent,  asynchonous  of  other  functions 
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TABLE  3.2-5  OPERATIONAL  CHARACTERISTICS  OF  FUTURE  FUNCTIONS 


(CONTINUED) 


CLEARANCE  GENERATION  (AERA) 

Operates  periodically  on  each  Level  1  flight 

I 

Storage 

Large 

II 

Process ing 
per  Operation 

P  =  +  K2  T,  T  =  number  of  Level  1  tracks 

=  medium,  Kj  =  large 

III 

Frequency 
of  Operation 

-once  per  5  minutes  on  each  Level  1  flight 

IV 

Types  of 
Processing 

I/O  0  Char.  0 

Calc.  Match  40% 

Log. 

V 

Amount  of 

Data 

In:  D  ;  Kj  Out:  D  = 

=  medium,  =  medium 

VI 

Response 

Time 

-10  seconds 

VII 

Operational 

Role 

Produces  automatically  delivered  flight  clearances 
to  Level  1  flights 

VIII 

Dependence 

Depends  on  properly  processed  flight  and  track  data 

TABLE  3.2-5  OPERATIONAL  CHARACTERISTICS  OF  FUTURE  FUNCTIONS 


(CONTINUED) 


TERMINAL  PATH  CONTROL 

Operates  periodically  on  all  flights  in  the  Terminal 
Control  Area 

, 

Storage 

Large 

--  -  -  .  -  -  - 

II 

Process ing 
per  Operation 

P  -  K, 

where  =  large 

■ 

III 

Frequency 
of  Operation 

once/5  seconds/track 

IV 

Types  of 
Processing 

■ 

I/O  0  Char.  0 

Calc.  50%  Match.  10% 

Log .  40% 

V 

Amount  of 

Data 

In:  D  -  Kk  Out:  D  - 

*  medium  ■  small 

VI 

Response 

T  ime 

~1  second 

VII  ! 

Operational  1  Produces  traffic  control  directives  for  use  by  controller 

Role  ■  in  the  terminal  area 

! 

_ i _ — - - - - - - - 

VIII 

Dependence 


Depends  on  Crack  data  from  DABS 
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TABLE  3.3-1.  ALLOCATION  OF  FUNCTIONS  IN  THE 
FUTURE  SYSTEM 


PROCESSOR 

Function 

R 

‘Coordinate  Conversion 

Dynamic  Simulation 

Data  Routing 

Fb 

Bulk  Store  Processing 

Flight  Plan  Activation 

Route  Conversion 

Flight  Plan  Position  Extrapolation  (Level  2) 
Fix-Time  Calculation  (Level  2) 

En  Route  Metering  (Level  2) 

Flight  Plan  Probe  (Level  2) 

Message  Routing 

Flight  Data  DBM 

O&E  Data  DBM 

c 

Conflict  Detection  and 

Resolution  ("Level  2) 

MSAW  (Level  2) 

Track  Data  DBM 

OSE  Data  DBM 

*TP 

‘Terminal  Path  Control 

Track  Data  DBM 

Fd 

Fix-Time  Calculation  (Level  2) 

Fosting  Determination  (Level  2) 

Message  Routing 

Flight  Data  DBM 

Dd'  Dr 

Display  Generation 

Display  Control 

Message  Processing 

*Fc 

♦Clearance  Generation  (AERA)  (Level  1) 

Flight  Data  DBM 

Track  Data  DBM 

T 

Track  Data  Format  Maintenance 

Association  Checking 

Flight  Plan  Modification  to  Tracking 

Track  Data  DBM 

S 

Supervisory  Functions 

Message  Processing 

System  Performance  Data  DBM 

Critical  Data  DBM 

xe 

Message  Processing 

s 

Supervisory  Functions 

Message  Processing 

System  Performance  Data  DBM 

Critical  Data  DBM 

_ie _ 

Message  Processing 

TABLE  3.3-2.  ALLOCATION  OF  DATA  BASES  IN  THE 
BASELINE  SYSTEM 


PROCESSOR 

DATA  BASE 

REMARKS 

Fb 

Flight  Data 

O&E  Del  tel 

Weather,  Airport 

C 

Track  Data 

O&E  Data 

Sensors,  MSAW,  Airport 

*TP 

♦Track  Data 

Terminal  Area 

Fd 

Flight  Data 

Dd  •  Dr 

Display  Data 

One  Sector  per  Processor 

S 

System  Performance  Data 
Critical  Data 

*FC 

♦Flight  Data 

T 

Track  Data 
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connection  to  the  sensors.  The  input  stream  of  radar  data  from 
the  DABS  sensor  network  is  fed  into  the  External  Interface 
Processor  <I£)  and  then  to  the  ICS  before  entering  the  Radar 
Processor.  The  role  of  the  Radar  Processor  diminishes,  being 
limited  to  coordinate  conversion  (sensor  site  to  facility), 
dynamic  simulation,  and  data  routing.  The  External  Interface 
Processor  <Ie)  serves  as  the  principal  link  with  the  outside 
world;  i.e.,  the  DABS  Sensor  network,  DABS  data  link,  the  Weather 
Processing  System,  Flight  Service  Station,  Central  Flow  Control 
Facility,  and  other  facilities.  The  roles  of  both  the  Bulk 
Flight  Data  Processor  (Fb)  and  the  Conflict  Processor  (C)  remain 
unchanged,  except  that  much  of  the  processing  in  Fb  and  all  in  C 
are  restricted  to  level  2  service  only.  The  Display  Flight  Data 
Processor  (F^)  performs  all  of  its  previously  designated 
functions  with  the  exception  of  Beacon  Code  Allocation.  This  is 
no  longer  required  because  the  DABS  System  uses  permanently 
assigned  beacon  codes,*  it,  too,  deals  mainly  with  level  2 
operations. 

Two  new  processors,  Fc  and  Tp,  have  been  incorporated.  Fc 
.generates  conflict-free  clearances  for  level  1  service;  Tp 
provides  the  means  for  consolidating  terminal  functions  with  en 
route  functions  and  performing  terminal  path  control  in  the 
center. 

The  Supervisory  Processor,  S,  is  the  means  by  which  control 
over  the  entire  system  is  maintained.  It  collects  critical  and 
performance  measurement  data  and  initiates  startup,  restart, 
startover,  and  configuration/reconfiguration  procedures. 

The  controller  work-station  in  the  Future  System,  while 
retaining  the  same  processing  elements,  an  R-position  Display 
Processor  (Dr),  a  D-position  Display  Processor  (Dd),  and  a 
Tracking  Processor  (T),  differs  in  function  from  the  Baseline 
System  in  that  the  Tracking  Processor  no  longer  does  tracking, 
per  se.  Track  data  is  supplied  from  DABS  via  the  R  processor  to 
the  appropriate  T  processor  for  the  en  route  sectors,*  flight  plan 
position  data  is  supplied  by  the  Fb  processor.  The  T  processor 
in  the  en  route  work-station  does  association  checking  between 
the  two  and,  under  the  appropriate  circumstances,  uses  flight 
plan  data  to  modify  or  supplement  the  track  data. 

The  controller  work-stations  are  identical  with  respect  to 
processors,  displays,  and  data  entry  devices  and  may  be  adapted 
by  software  (or  firmware)  to  En  Route  level  1  or  level  2,  or  to 
Terminal  Approach/Departure  Control. 

3.3.3  System  Sizing 

The  Future  System  was  analyzed  in  the  same  way  as  the 
Baseline  System  to  obtain  the  comparative  processing  numbers  for 
each  of  the  processors  and  the  comparative  channel  requirements 
into  and  out  of  each  of  them.  The  CPNs  are  shown  in  Table  3.3-3 
and  the  channel  requirements  in  Table  3.3-4. 
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TABLE  3.3-4  COMMUNICATIONS  CHANNEL  REQUIREMENTS  -  FUTURE  SYSTEM 


PROCESSOR 

COMMUNICATIONS  CHANNEL  TYPE 

SMAL 

L 

MEDIUM 

LARG1 

3 

IN 

OUT 

IN 

OUT 

IN 

OUT 

R 

C  (A)  * 

C 

C  (A) 

C 

2C  (A) 

2C 

Fb 

A  (C) 

B 

A  (C) 

C 

A  (C) 

C 

Fc 

C  (C) 

B 

C  (C) 

B 

C  (2C) 

C 

C 

B  (B) 

B 

B  (B) 

B 

C  (B) 

B 

T 

P 

C  (B) 

B 

C  (B) 

B 

C  (B) 

B 

Fd 

A  (C) 

C 

B  (C) 

C 

B  (C) 

C 

Dd 

A  (A) 

A 

A 

A 

A  (A) 

A 

T 

B  (A) 

B 

B  (A) 

C 

B  (A) 

C 

Dr 

B  (A) 

A 

A  CA) 

A 

A  (A) 

A 

J. 

B  (A) 

C 

C  (A) 

C 

C  CA) 

2C 

S 

SC 

A  (3C) 

4C 

A  C4C) 

5C 

A  (4C) 

* 

Figures  in  Parentheses  are  for  Redistribution  of  Critical  Data  for  Retart. 


Type  A  capacity  *  9600  bits  per  second 
Type  B  capacity  »  33600  bits  per  second 
Type  C  capacity  -  300000  bits  per  second 
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4.  ANALYSIS  OF  ISSUES 


The  question  addressed  throughout  this  study  has  been,  "What 
will  be  the  effect  in  the  1990 's  of  having  chosen  a  distributed 
processing  concept  for  the  9020®  replacement?''  The  answer  is 
derived  in  two  ways:  1)  by  discussing  certain  basic  issues  which 
are  likely  to  arise  in  conjunction  with  changes  and  improvements 
to  the  system,  and  2)  by  examining  the  effects  of  a  sample 
scenario  on  a  strawman  model  of  a  future  ATC  system.  In  the 
first  case,  reasoning  is  from  the  general  to  the  specific,  from 
knowledge  of  general  system  behavior  to  the  more  specific  ATC 
application.  In  the  second,  reasoning  goes  from  the  specific, 
somewhat  fanciful  implementation  to  the  more  general  ATC 
application.  The  two  lines  of  reasoning  meet  at  the  ATC 
application,  for  what  is  specific  to  the  one  is  general  to  the 
other. 

As  general  background  to  this  discussion,  it  may  be  useful 
to  consider  the  level  of  technology  of  the  system  that  might  be 
procured  to  replace  the  9020.  It  can  be  assumed  that  it  will  be 
equivalent  to  what  might  be  commercially  available  in  about  1984. 
Since  the  results  of  this  study  are  not  particulary  sensitive  to 
the  level  of  the  technology  assumed,  a  broad  statement  of  what 
might  be  expected  will  suffice.  A  quick  survey  of  some  current 
literature  [1-4]  leads  to  the  following  assertions  about  the  1984 
computer  systems: 

1)  Great  amounts  of  processing  capability  will  be 
available  in  the  form  of  microprocessors,  e.g.  a  32  bit 
computer  on  a  single  chip.  [4] 

2)  Random-access  memory  with  one  megabit  on  a  single  chip 
will  be  available  and  the  price  will  approach  .02  cents 
per  bit.  [4] 

3)  Electronic  mass-storage  devices  such  as  bubble  memories 
and  charge-coupled  devices  will  be  available  and  cost- 
effective  in  the  range  of  4-40  megabits.  [3] 

4)  Communications  links  such  as  fiber  optics  will  allow 
wide-band  (400  Mbps)  communications  over  distances  of 
ten  kilometers.  [1] 

A  distributed  system  built  with  this  kind  of  technology 
would  be  extremely  powerful  compared  to  today's  NAS  system, 
leading  one  to  consider  factors  other  than  raw  processing  power 
and  memory  capacity  as  the  more  important. 

4.1  BASIC  ISSUES 

From  the  myriad  of  issues  that  have  to  be  faced  in  the 
1990 's  with  respect  to  the  ATC  computer  subsystem,  four  seem  to 
be  of  primary  importance:  The  effect  of  functional  modification 

on  the  system,  the  effect  of  increasing  load,  the  influence  of 


new  technology,  and  the  general  area  of  software  design, 
implementation,  and  maintenance. 

With  regard  to  distributed  processing  systems,  it  has  become 
clear  during  this  study  that,  the  key  to  the  success  of  any 
particular  design  is  the  efficacy  of  the  interprocessor 
communications  subsystem,  and  that  the  critical  performance 
measurement  criteria  involve  synchronization  of  the  system  and 
response  time  of  the  processes.  The  other  aspects,  such  as 
amounts  of  processing  power  and  memory  at  each  node,  seem 
straight-forward  by  comparison.  Therefore,  most  of  the 
discussion  which  follows  will  be  concentrated  on  the  dynamic 
behavior  of  the  system  and  its  interaction  with  the  issues. 

4.1.1  Functional  Modification 

A  fundamental,  but  generally  unwritten,  requirement  which 
every  system  design  is  expected  to  meet  is  that  it  be  amenable  to 
changes  in  the  remaining  requirements.  Among  other  things,  these 
changes  could  involve  adding  a  new  function,  or  modifying  one  or 
more  of  the  existing  functions.  How  amenable,  then,  is  a  system 
implemented  under  a  distributed  concept  to  functional 
modjf ication? 

The  structure  of  the  software  of  a  system  has  been 
recognized  as  the  quality  that  can  lead  to  designs  which  are  easy 
to  modify  in  the  ways  being  discussed  here.  Well-structured 
programs  have  the  property  of  being  composed  of  loosely-coupled, 
independent  modules,  where  "loosely-coupled"  means,  essentially, 
related  only  through  information  passed  as  a  part  of  the  calling 
operation  (as  opposed  to  sharing  global  variables,  for  instance). 

A  problem  in  the  system  design  process  is  the  need  to  match 
the  structure  of  the  software  to  the  structure  of  the 
requirements  and  specifications,  while  also  matching  the 
structure  of  the  hardware.  It  is  not  always  easy  to  maintain 
this  two-level  matching,  even  with  the  aid  of  sophisticated  high- 
level  languages  and  their  compilers  and  complex  operating 
systems,  when  the  hardware  is  specified  first  and  the  software  is 
then  designed  to  fit  it.  On  the  other  hand,  it  would  seem  that 
if  the  software  structure  were  matched  to  the 

requirement/specification,  and  then  the  hardware  structure  were 
designed  to  match  the  software,  the  process  could  become  nearly 
optimal . * 

In  practice, a  certain  amount  of  give  and  take  in  the  design 
process  between  hardware  and  software  structures  cannot  be 
avoided  because  the  hardware  is  not,  after  all,  continuously 
variable  in  structure  and  cannot  be  matched  exactly  to  an 


*An  excellent  example  of  this  process  is  the  DABS  system,  where 
the  concept  of  the  hardware  being  matched  to  the  design  was 
enunciated  in  the  Request  for  Proposals. 


arbitrary  software  structure.  Because  of  its  inherent 
modularity,  a  distributed  processing  architecture  is  very 
flexible  and  could  be  matched  more  easily  than  most  to  a 
predefined  software  structure. 

It  may  then  be  assumed  that  a  9020®  replacement  system  based 
on  the  distributed  processing  concept  would  attain  the  matching 
of  the  software  structure  to  the  requirement/specification 
structure  and  the  hardware  structure  to  the  software  structure. 
The  question  then  becomes:  how  easily  is  the  change  in 
requirement  passed  through  the  software  structure,  accomodated  by 
the  hardware  structure? 

There  will  be  a  range  of  possible  functional  modifications, 
some  of  which  have  little  or  no  effect  on  the  software  structure, 
others  which  seriously  perturb  it.  A  new  function  added  to  the 
system,  which  needs  only  modest  amounts  of  input  data  at  low 
frequency,  produces  only  modest  amounts  of  output  and  has 
virtually  no  effect  on  other  processing,  can  be  treated  in  a 
trivial  way,  possibly  by  assigning  it  to  a  new  independent 
processor  added  to  the  system  just  for  this  purpose.  The  more 
important  cases  occur  when  the  functional  modifications  require 
large  amounts  of  data  not  previously  available  produce  new  and/or 
large  amounts  of  output  or  strongly  effect  the  operating  of  the 
other  functions. 

It  is  possible  to  infer  the  structure  of  a  possible  1980's 
ATC  system  from  Figure  2.2-1,  Baseline  System  Functional  Block 
Diagram;  A  possible  1990 's  system  is  presented  in  Figure  3.2-1, 
Future  System  Functional  Block  Diagram.  Suppose  that  the  1980 's 
structure  was  mapped  onto  a  distributed  processing  system  in  some 
reasonable  way.  Then  the  question  would  be  whether  that 
processing  system,  hardware  and  software,  could  be  modified  so 
that  it  would  accept  a  mapping  of  the  1990's  structure. 

If  the  system  were  built  with  current  technology,  one  would 
examine  first-order  effects,  such  as  processing  capacity  and 
memory  size  requirements,  and  be  able  to  detect  possible  problem 
areas.  With  the  technology  assumed  for  the  9020  replacement 
system,  one  can  envision  a  system  composed  of  a  large  number  of 
microcomputers,  each  of  which  is  equivalent  in  processing  to  an 
IBM  4341®  or  a  DEC  VAX-11/780®.  This  is  the  "hardware  overkill" 
assumption,  that  every  node  has  all  the  processing  and  memory 
capacity  that  it  will  ever  need. 

There  are  other  factors,  however,  which  will  affect  the 
feasibility  of  the  structural  mapping:  communications,  control, 
response,  reliability,  and  recovery,  among  others.  The  initial 
system  design  presumably  accounts  for  each  of  these  factors  in  an 
acceptable  fashion;  the  changes  in  the  design  which  produce  the 
future  System  must  not  be  allowed  to  compromise  system 
performance  in  those  areas. 
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The  key  to  the  performance  of  a  distributed  processing 
system  in  the  ATC  application  will  be  the  suitability  and 
adaptability  of  the  Interprocessor  Communications  Subsystem 
(ICS).  Figure  2.2-1  shows  two  main  streams  of  information, 
Target/Track  Data  and  Flight  Data,  flowing  through  the  system. 

As  they  flow  from  Sensors  to  Display  and  from  Bulk  Store  or  other 
source  to  Display,  they  interact  at  Association  Checking  and 
Flight  Plan  Aided  Tracking.  There  are  also  streams  of  data 
flowing  to  the  Critical  Data  and  System  Performance  Data 
recording  functions.  Super-imposed  on  these  streams  is  a 
constant  circulation  of  messages  which  flow  into  the  system  from 
controller  and  remote  inputs  and  leave  the  system  at  controller 
displays  and  remote  outputs.  Other  message  traffic  is  absorbed 
or  generated  by  the  system  itself. 

The  system  diagrammed  in  Figure  3.2-1  is  the  same  in  many 
respects.  However,  Automatic  Clearance  Generation  and  Terminal 
Path  Control  have  been  added,  and  Track  Data  rather  than  Target 
Data  is  supplied  by  the  sensor.  These  differences  will  cause  a 
large  change  in  the  way  Track  Data  is  handled.  For  instance,  in 
the  Baseline  System  the  Track  Data  supplied  to  the  Conflict  Alert 
and  Conflict  Resolution  functions  comes  from  the  individual 
sector  Track  processors,  while  in  the  Future  System,  Track  Data 
would  come  from  the  DABS  sensor  through  the  Coordinate  Conversion 
function  in  the  R  processor.  Furthermore,  the  Automatic 
Clearance  Generation  and  Terminal  Path  Control  functions  in  the 
Future  System  will  be  users  of  Track  Data,  requiring  additional 
data  paths  not  found  in  the  Baseline  System. 

It  can  be  assumed  that  the  communications  system  for  the 
1980's  system  will  be  designed  both  statically  and  dynamically, 
i.e.,  the  amount  of  traffic  between  processors  will  be 
calculated,  and  links  of  the  proper  bandwidth  will  be  provided. 
Furthermore,  the  proper  message  handling  software  and  hardware 
will  be  provided  at  each  processor  so  that  transmission  delays 
will  be  kept  within  specified  limits.  Conversion  to  the  1990's 
system  will  require  a  recalculation  of  link  requirements  and  a 
re-evaluation  of  message  handling  capabilities  in  view  of  new 
communications  needs. 

It  may  be  that  one  or  more  interprocessor  links  will  be 
found  to  have  too  little  capacity  for  the  amount  of  data  to  be 
transferred  in  the  new  system.  Because  of  its  very  nature,  one 
would  expect  that  a  distributed  processing  configuration  could  be 
modified  or  adapted  relatively  easily  to  meet  the  new 
requirement;  a  higher-speed  channel  could  be  substituted,  an 
additional  parallel  link  could  be  supplied,  or  a  dedicated  direct 
link  could  be  added. 

A  more  subtle  problem,  with  a  less  clear  solution,  occurs 
when  the  patterns  of  the  message  traffic  shifts  in  such  a  way 
that  it  starts  to  overload  one  or  more  of  the  nodes.  That  is, 
the  well-known  phenomenon  occurs  where  queue  lengths  begin  to 
grow  and  delays  to  get  longer  as  the  capacity  of  the  queue  server 


4-4 


is  approached.  Even  without  overflow,  the  performance  of  the 
system  may  be  severely  degraded  by  the  delays  which  are  inherent 
in  the  physical  as  well  as  logical  transfer  of  messages  between 
processes. 

These  delays  contribute  also  to  possible  problems  in  control 
and  synchronization  of  processes.  Without  a  close  coupling,  such 
as  global  memory  between  processors,  the  control  programs  in  each 
have  no  way  of  synchronizing  operations  other  than  by  the  same 
communications  link  by  which  messages  are  sent.  A  breakdown  in 
the  message  traffic  then  causes,  or  at  least  contributes  to,  a 
breakdown  in  control.  With  a  distributed  system  the  modification 
of  a  working  system  requires  much  greater  care  in  this  area  than 
for  a  more  closely  coupled  type. 

The  response  exhibited  by  a  system  is,  of  course,  dependent 
on  the  delays  which  occur,  so  that  what  has  already  been  said 
applies.  For  the  purpose  of  control  and  synchronization,  it  is 
enough  to  know  what  the  delays  are;  for  the  purpose  of 
maintaining  response  time  within  requirements,  it  is  necessary  to 
be  able  to  limit  delays  at  each  step  of  a  chain  of  processes. 

One  way  to  make  this  easier  is  to  reduce  the  number  of  steps  in 
the  chain  by  keeping  the  data  near  the  place  where  they  are  used. 
This,  however,  leads  to  maintaining  multiple  copies  of  data  which 
are  used  by  a  number  of  distributed  functions,  which  in  turn 
leads  to  the  possibility  of  synchronization  problems.  A  tradeoff 
must  then  be  made  between  ease  of  access  to  a  distributed  data 
base  and  ease  of  control  of  the  integrity  of  a  centralized  data 
base.  The  modification  of  the  system  must  include  judicious 
consideration  of  this  tradeoff. 

The  matters  of  system  reliability  (hardware  and  software), 
error  detection,  recovery,  and  restart  will  greatly  influence  the 
design  of  the  1980 's  ATC  system;  the  particular  nature  of  the 
distributed  processing  configuration  will  require  special 
attention.  The  difficulties  that  must  be  faced  in  producing  a 
system  of  this  type  which  can  detect  and  recover  from  faults  are 
being  faced  [5]  but  are  not  well  understood  at  this  time.  By 
1984,  our  assumed  year  for  design  freeze,  there  should  be  a 
better  understanding  of  the  questions  being  raised  now,  and  by 
the  1990 's,  there  may  well  be  a  number  of  new  techniques 
developed.  These  techniques  would,  if  available,  make  the 
modification  and  further  development  of  the  ATC  system  in  a 
distributed  configuration  quite  reasonable.  Lack  of  progress  in 
this  area  during  the  next  few  years,  however,  would  tend  to  make 
this  concept  less  attractive.  In  fact,  of  all  aspects  to  be 
considered,  this  matter  of  reliable  operation  should  be  the 
pacing  one,  and  the  one  on  which  any  decision  to  adopt 
distributed  processing  should  depend. 

4.1.2  Increasing  Traffic  Load 

It  is  axiomatic  that  the  load  on  the  system  will  increase 
over  the  years,  and  that  the  system  must  be  planned  to  accomodate 
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the  increase.  Though  one  can  assume  very  large  memory  sizes  and 
processing  capacities,  there  are  limits;  the  processors  and 
memories  are  finite.  Given  that  the  ATC  system  is  implemented  as 
a  distributed  system  and  that  additional  traffic  load  must  be 
accomodated,  what  are  the  problems,  or  advantages,  to  be 
encountered? 

The  impact  of  increased  traffic  load  will  be  felt  over  the 
whole  system,  though  not  uniformly,  in  the  requirement  for 
increased  processing  capability,  increased  memory  and  increased 
communications  capacity.  This  is  essentially  a  hardware  problem, 
assuming  the  software  has  been  properly  parameterized.  One 
obvious  problematical  characteristic  of  the  distributed  system, 
as  defined  here,  is  the  fact  that  memory  and  processing  are  not 
shareable  between  functions  except  by  functional  redesign.  That 
is,  excess  capacity  at  processor  A  which  carries  out  function  M 
cannot  easily  be  used  to  relieve  a  shortage  at  processor  B  doing 
function  N.  The  implication  is  that  each  component  of  the  system 
must  be  sized  separately  and  provided  with  capacity  to  meet  peak 
demands  plus  provision  for  growth.  Furthermore,  there  is  no  way 
to  average  out  uncertainties  in  the  estimates,  compensating  for 
an  underestimation  in  one  part  with  a  possible  overestimation  in 
another . 

There  are  a  number  of  ways  in  which  the  increased 
capabilities  could  be  provided:  first,  it  may  be  possible  to 
estimate  what  the  future  load  will  be  and  to  size  the  system 
correspondingly.  Essentially,  one  would  be  buying  the  1995 
capacity  in  advance.  This  is  the  riskiest  method  as  well  as 
being  somewhat  wasteful  of  resources. 

Secondly,  if  the  hardware/software  system  is  designed 
properly,  the  capacity  could  be  expanded  by  adding  modules. 
Increasing  storage  capacity  this  way  is  relatively  easy,  but 
increasing  processing  capability  by  adding  module?  is  probably 
not  feasible  in  a  system  of  this  type. 

A  third  way  might  be  to  adopt  the  policy  of  expanding  system 
capacity  continually  and  regularly  by  replacing,  in  a  systematic 
way,  some  fraction  of  the  system  each  year  with  new,  faster  or 
larger  components.  If  one-tenth  of  the  system  were  replaced 
every  year,  then  at  the  end  of  ten  years,  the  whole  system  would 
be  renewed.  The  initial  system  could  be  designed  with  capacity 
to  handle  traffic  at  a  level  predicted  for  some  number  of  years, 
say  n,  in  the  future.  The  new  hardware  being  incorporated  into 
the  system  each  year  would  be  sized  to  handle  traffic  (n+10) 
years  in  the  future.  At  the  end  of  the  ten  years,  the  system 
would  be  renewed  and  sized  for  n  years  into  the  future  and  the 
cycle  could  repeat. 

This  kind  of  piecemeal  expansion  would  be  relatively  easy  to 
schedule  with  a  distributed  system  both  from  a  hardware  and  a 
software  viewpoint.  (See  also  Section  4.1.3). 
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4.1.3  Introduction  of  New  Technology 

Computer  technology  will  continue  to  advance  after  the 
replacement  ATC  system  has  been  put  into  service.  The  question 
that  remains  is  will  the  FAA  will  find  it  easy  to  take  advantage 
of  such  developments  if  the  ATC  system  is  built  as  a  distributed 
processing  system? 

Why  would  it  be  advantageous  to  introduce  non-standard 
equipment  into  an  already  well-designed,  smoothly  operating 
system?  There  are  three  obvious  reasons:  to  improve  the 
performance  of  the  system,  to  improve  the  reliability  of  the 
system,  or  to  provide  a  new  service  with  the  system.  In  each 
case,  the  new  hardware  could  be  a  better  version  of  equipment 
already  in  use  or  be  a  new  type  of  equipment. 

At  first  glance,  it  seems  clear  that  a  distributed  system 
would  be  most  conducive  to  this  kind  of  equipment  substitution  or 
addition  because  of  the  inherent  modularity  of  the  design.  This 
will  be  true  as  long  as  the  proper  provisions  have  been  made  for 
this  future  expansion,  and  the  provisions  have  been  based  upon 
real  standards.  Unfortunately,  requirements  tend  to  develop  in 
ways  different  from  predictions  and,  as  technology  develops, 
standards  change  to  keep  pace.  Thus,  the  problems  of  matching 
unlike  equipment,  or  of  introducing  equipment  whose  use  requires 
significant  change  to  existing  hardware  or  software  are  not 
automatically  solved. 

However,  if  that  kind  of  problem  is  discounted  as  unlikely, 
or  manageable  at  worst,  then  the  modularity  and  loose-coupling  of 
the  distributed  system  should  make  it  relatively  easy  to  add  the 
newer  technologies  from  a  functional  viewpoint. 

Consider  an  extreme  case:  suppose  a  new  solid-state  mass- 
storage  device  was  offered  which  incorporated  data-base 
management  functions  and  that  the  Track  Data  were  to  be  stored  on 
the  device.  Access  to  data  on  any  track  could  then  be  in  terms 
of  any  attribute  of  the  track.  The  conflict  detection  program 
could  then  not  maintain  its  own  data  base  but  could  instead 
inquire  of  the  Track  Data  manager  for  all  tracks  within  certain 
areas.  In  other  words,  the  course  filter  part  of  the  algorithm 
would  be  implemented  in  the  data  management  processor  as  part  of 
the  data  access  software.  This  would  require  a  rather  extensive 
reworking  of  the  conflict  functions,  but  other  functions  could 
continue  to  operate  as  before,  accessing  the  data  in  the  usual 
fashion  by  track  number  or  whatever,  until  it  was  necessary  or 
convenient  to  change  them.  Note,  however,  that  a  redesign  of 
this  type  would  require  careful  analysis  of  the  implications  to 
inter-process  communications  (  Section  4.1.1). 

4.1.4  Software  (Design,  Implementation.  Maintenance) 

As  emphasized  previously,  the  structure  of  the  software 
should  match  the  structure  of  the  hardware.  Indeed,  the  software 
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should  be  designed  first,  and  the  hardware  assembled  to  match  it. 
If  the  software  is  designed  in  a  nicely  structured  way,  with 
loosely-coupled,  so-called  information-hiding  modules,  then  a 
distributed  processing  system  of  loosely-coupled,  independent 
processors  can  be  assembled  to  match  the  software  structure. 

It  can  be  assumed  that  the  1980 's  system  will  be  reasonably 
designed,  implemented,  and  tested,  so  that  it  may  exhibit,  with  a 
high  degree  of  confidence,  those  general  properties  that  any 
viable  system  should  possess.  These  are  (as  paraphrased  from  a 
slightly  different  context  (6]): 

1)  Freedom  from  deadlock, 

2)  Completeness  (the  ability  to  handle  all  conditions  that 
might  arise) , 

3)  Stability  (the  ability  to  return  to  "normal"  behavior 
after  an  initial  or  temporary  perturbation), 

4)  Progress  (the  absence  of  cyclic  behavior  where  no 
useful  activity  takes  place), 

5)  Freedom  from  overflow,  and 

6)  Termination  (arrival  at  the  desired  final  situation). 

An  important  question  is  the  extent  to  which  the  system  can 
be  modified  to  fulfill  its  new  functional  requirements  as  well  as 
the  still-relevant  older  functional  requirements,  while  still 
maintaining  its  integrity  as  represented  by  the  above  listed 
general  requirements. 

Since  the  software  will  be  composed  of  loosely-coupled, 
single-entry  modules,  each  module  can  be  modified,  or  even 
replaced  by  a  different  module,  as  long  as  the  interface 
requirements,  in  and  out,  do  not  change  and  all  timing 
constraints  are  satisfied.  This,  of  course,  makes  the  software 
maintenance  process  relatively  simple  because  interactions  with 
other  modules  are  constrained  to  those  through  the  interface. 

This  is  true  of  many  modular  systems,  but  in  the  distributed 
processing  system  it  is  enforced  by  the  physical  structure. 

A  change  in  system  design,  however,  is  not  the  same;  here  it 
is  a  matter  of  changing  the  inputs  and  outputs  of  modules  to 
accomplish  new  purposes.  The  changes  being  suggested  for  the  ATC 
system  are  quite  extensive,  and  each  one  will  require  changes  in 
many  modules.  These  changes  are  no  more  difficult  in  principle 
to  design,  code,  and  implement  in  a  distributed  system  than  any 
other  type;  in  fact,  the  structure  discussed  above  may  make  it 
easier  than  others. 

In  practice,  the  ease  with  which  these  changes  can  be  coded 
and  implemented  will  depend  to  a  large  degree  on  the  extent  and 
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the  completeness  of  the  software  support  available.  Ideally,  a 
high  order  language  (HOL)  should  be  provided  which  would  support 
the  distributed  system,  with  built  in  process-level  message 
protocols,  process  synchronization  primitives,  and  the  like.  If 
the  processors  of  the  system  are  dissimilar,  this  fact  should  be 
transparent  to  the  programmer,  who  should  be  able  to  write  a 
process  for,  and  assign  it  to,  any  processor  (capable  of 
performing  the  process)  in  exactly  the  same  way.  One  possibility 
which  should  be  seriously  considered  is  ADA,  the  new  Department 
of  Defense  standard  language. 

Furthermore,  there  should  exist  a  distributed  operating 
system  (OS)  which  can  implement  the  language  constructs  in 
software  or  hardware  to  ensure  process  synchronization  and  system 
integrity.  The  relationship  of  the  HOL  and  OS  to  the  detection 
of,  and  recovery  from,  hardware  and  software  faults  should  be 
well  understood. 

There  are  other  areas  of  distributed  processing  which  need 
investigating  [7],  but  not  all  of  them  apply  to  the  particular 
type  of  configuration  being  considered  here.  Progress  is  being 
made  in  the  language  and  operating  system  areas  [e.g.,  8,  9]  and 
it  may  be  assumed  that,  with  the  interest  being  shown  in 
distributed  processing,  it  will  continue.  Note  in  particular 
that  the  nature  of  the  distributed  processing  system  defined  here 
does  not  demand  an  OS  which  solves  the  really  difficult  problem 
of  resource-sharing  among  processes.  In  this  system,  each 
process  is  permanently  assigned  a  particular  processor  rather 
than  being  temporarily  assigned  any  processor  which  happens  to  be 
available. 

Any  assessment  of  the  viability  of  design  concept  for  the 
ATC  system  should  place  great  emphasis  on  software  development 
and  maintenance  facilities  because  this  is  where  the  greatest 
payoff  is  to  be  found.  In  assessing  a  distributed  processing 
concept,  the  scrutiny  should  be  even  more  careful  since  the 
development  state  of  software  support  is  at  the  moment  so 
uncertain.  At  the  very  least,  the  compiler  should  support  all  of 
the  processors,  as  mentioned  above;  linkers,  loaders  and  run-time 
facilities  should  support  the  configuration  in  a  uniform  manner; 
and  debugging  and  test  aids  should  allow  controlled  testing  of 
all  or  part  of  the  system.  The  whole  package  should  support  and 
enforce  structured  design  and  programming  practices. 

4.2  SPECIFIC  ISSUES 

In  developing  the  model  ATC  system  used  in  this  analysis,  a 
certain  number  of  assumptions  were  made  over  and  above  the 
specific  provisions  of  the  scenario.  One  of  these,  in 
particular,  had  a  large  effect  on  the  form  of  the  Future  System, 
and  on  the  way  the  Baseline  System  might  evolve  into  the  Future 
System.  This  assumption  was  that  track  data,  rather  than  target 
data,  would  be  transmitted  from  the  DABS  network  to  the  ATC 
system.  The  reason  for  assuming  this  is  not  that  it  is  a  likely 
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thing  to  happen,  although  the  suggestion  has  been  made  that  this 
is  the  way  the  ATC  system  should  operate.  The  real  reason  is 
that  it  would  be  an  example  of  a  really  major  change  in  the  way 
the  Future  System  would  operate  as  compared  to  the  Baseline 
System,  requiring  a  major  modification  for  the  Baseline  System  to 
accomodate  the  changes,  thereby  furthering  the  purpose  of  this 
study,  to  examine  the  effects  of  change  on  the  system. 

4.2.1  Al 1-DABS  Environment 

The  DABS  will  provide  the  ATC  system  with  extremely  high- 
quality  surveillance  data,  as  well  as  a  digital  data-link  not  now 
available.  Each  of  these  will  have  an  effect  on  the  functioning 
of  the  future  en  route  system. 

The  surveillance  data  may  be  so  good  that  track  data 
smoothed  and  predicted  track  positions  and  calculated  velocities 
and  accelerations,  produced  by  the  DABS  tracker  may  be  of  such 
high  quality  that  it  may  be  used  by  the  ATC  system  in  lieu  of 
similar  quantities  calculated  by  the  surveillance  data  user.  It 
is  assumed  in  this  analysis  that  this  is  the  case. 

It  may  also  be  that  the  DABS  data  link  may  be  so  useful  and 
be  available  so  inexpensively  (because  of  developments  in 
electronics)  that  it  is  very  widely  or  even  universally,  adopted 
by  users  of  the  ATC  system,  commercial,  military,  and  general 
aviation.  It  is  assumed  that  this  is  also  the  case. 

A  third  assumption,  based  on  all  DABS  environment,  is  that 
data  is  collected  in  a  network  of  DABS  sensors  which  transmit  the 
data  to  the  en  route  center  through  a  (logically)  single 
interface.  The  ATC  system  receives  track  data  from  multiple 
sites  which  have  among  themselves  selected  and  transmitted  the 
best  of  the  available  data  on  each  track  under  surveillance. 

Track  positions  are  given  with  respect  to  the  originating 
sensors,  and  coordinate  conversion  takes  place  in  the  center 
processor . 

These  three  assumed  characteristics  of  the  DABS  environment 
have  a  great  effect  on  the  form  of  the  Future  System  and  the  way 
it  is  derived  from  the  Baseline  System. 

The  first  and  most  obvious  change  from  Baseline  to  Future  is 
in  the  requirement  for  External  Interface  processing.  All  of  the 
sensor  data  in  coming  into  the  center  and  all  of  the  data  link 
messages  both  into  and  out  of  the  center  are  added  to  the 
Baseline  System  load  in  this  area.  Comparison  of  the  comparative 
processing  numbers  for  the  External  Interface  Processor  (Ie)  for 
the  Baseline  and  Future  System  show  that  the  processing 
requirement  is  increased  by  a  factor  of  3  to  4  from  the  small  to 
the  large  center.  The  communications  load  into  the  processor 
from  the  rest  of  the  system  (to  be  transmitted  to  the  external 
world)  is  increased,  except  for  the  small  center,  so  that  the 
channel  requirement  moves  up  one  notch,  from  medium  speed  to  high 
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speed.  The  load  out  of  the  processor  (from  the  external  world) 
to  the  rest  of  the  system  is  also  increased  so  much  that  for  the 
large  center,  two  high-speed  channels  are  needed  to  replace  a 
medium-speed  channel. 

It  is  an  implicit  assumption  in  all  of  this  analysis  that 
the  same  hardware  is  to  be  used  in  the  centers  regardless  of 
size.  That  is,  if  a  processor,  memory  or  communications  link  is 
not  naturally  modular,  or  if  a  function  cannot  be  divided  among 
parallel  processors,  then  the  unit  will  be  sized  to  handle  the 
center  with  the  largest  requirement. 

The  message  processing  function,  assigned  to  the  External 
Interface  Processor,  can  obviously  be  divided  among  as  many 
parallel  processors  as  is  practicable.  In  fact,  this  would 
probably  be  done  in  any  implementation  for  reasons  other  than  the 
size  of  the  processor,  such  as  redundancy  for  failure  protection. 
In  a  distributed  processing  system  the  messages  received  from  the 
outside  world  would  be  routed  by  the  Ie  processor  through  the 
Interprocessor  Communication  Subsystem  addressed  to  a  processor, 
rather  than  being  addressed  to  a  process  and  forwarded  through 
some  operating  system  function  which  would  handle  the  physical 
addressing.  This  is  an  example  of  the  kind  of  simplicity  which 
is  attained  through  the  matching  of  the  functional/software 
structure  and  the  hardware  structure  in  a  distributed  system. 

All  of  the  sensor  data  goes  in  the  Future  System  to  a  single 
Radar  Processor  (R)  which  now  has  the  tasks  of  coordinate 
conversion  from  sensor  to  center  coordinates  and  routing  of  the 
data  to  the  proper  recipients.  A  comparison  of  Comparative 
Processing  Numbers  (CPNs)  shows  that  the  R  processor  used  to 
process  ATCRBS  data  in  the  Baseline  System  is  about  the  right 
size  to  handle  the  tasks  in  the  Future  System.  If  one  accepts 
that  a  single  size  processor  can  be  used  for  small,  medium,  and 
large  centers  in  the  Baseline  System,  a  size  range  of  about  four, 
then  that  same  size  processor  would  be  appropriate  for  the  R 
processor  in  the  Future  System. 

The  difficulty  in  changing  the  major  functions  of  the  R 
processor  is,  once  again,  the  communications  requirements.  The 
amount  of  data  moved  into  and  out  of  each  processor  will  be 
increased  dramatically;  instead  of  data  from  a  single  sensor 
entering  from  the  external  environment  and  leaving  via  the  ICS, 
data  from  all  of  the  sensors  must  enter  and  leave  via  the  ICS. 

If  the  bandwidth  in  and  out  is  a  problem,  then  an  obvious 
solution  is  to  replicate  the  R  processor  and  split  the  task  among 
them.  From  a  functional  point  of  view  this  would  be  easy  to  do 
since  the  processing  of  each  track  report  is  essentially 
independent  of  any  other.  It  is  also  reasonable  to  do  this  from 
the  reliability  point  of  view  since  a  failure  of  one  processor 
would  have  no  effect  on  the  others  except  to  make  their  share  of 
the  load  somewhat  larger. 


The  communications  aspect  also  includes  the  addressing  and 
access  schemes.  Compare  the  flow  of  surveillance  data  in  the  two 
systems.  In  the  Future  System,  the  sensor  data  are  transmitted 
from  the  Ie  processor  and  destined  for  any  one  of  the  R 
processors,  a  kind  of  single  queue,  multiple  server  discipline 
not  used  in  the  Baseline  System.  In  the  next  stage,  the 
processed  track  data  are  transmitted  from  the  R  processor  with 
each  message  addressed  to  some  subset  of  the  other 
processors:  the  messages  containing  track  data  for  level  1 
flights  are  sent  to  the  Clearance  Generation  Processor  (Fc)  and 
the  Tracking  Processor  (T)  at  the  level  1  workstations,  track 
data  for  level  2  flights  are  sent  to  the  Conflict  Processor  (C) 
and  the  T  processors  at  the  level  2  workstations,  and  track  data 
for  terminal  flights  are  sent  to  the  Terminal  Processor  (Tp)  and 
the  T  processors  at  the  Terminal  Workstations.  These  are  either 
multiple  messages,  or  messages  with  multiple  addresses.  In  the 
Baseline  System,  radar  data  were  sent  from  each  R  processor  to 
the  appropriate  T  processor,  and  track  data  were  sent  from  the  T 
processors  to  the  C  processor. 

The  point  of  all  this  is  that  the  surveillance  data 
distribution  scheme  is  completely  changed,  both  in  the  pattern  of 
distribution  and  in  the  protocol  of  distribution.  The 
flexibility  and/or  modularity  of  the  Interprocessor 
Communications  Subsystem  will  determine  the  feasibility  of 
modifying  the  system. 

Finally,  the  use  of  track  data  from  DABS  will  relieve  the  T 
processors  in  the  workstations  of  most  of  their  processing  load. 
This  should  be  of  no  real  consequence,  although  it  could  be 
looked  upon  as  "wasted"  capability. 

4.2.2  Addition  of  Level  1/Level  2  Service 

The  scenario  for  the  Future  System  describes  a  new  type  of 
ATC  service,  level  1  service,  to  be  provided  to  part  of  the 
airspace  in  the  1990's.  Level  2  service,  which  is  similar  to 
today's  positive  control,  will  be  provided  in  the  rest  of  the 
controlled  space,  outside  of  the  Terminal  Control  Areas 
(discussed  in  the  next  section).  The  new  service  is  described  as 
highly  automated,  positive  control  with  central,  ground- 
controlled  separation  and  flow  management. 

It  was  perceived  during  the  development  of  the  functional 
diagram  of  the  Future  System  that  the  level  1  function,  Automatic 
Clearance  Generation,  was  essentially  independent  of  the  parts  of 
the  system  which  provide  the  level  2  service;  Automatic  Clearance 
Generation  is  shown  in  Figure  3.2-1  as  accepting  Flight  and  Track 
Data  from  the  respective  data  bases  and  producing  clearances  and 
commands  for  transmission  to  aircraft  via  the  data  link. 
Interaction  with  the  controllers  is  provided  by  message  input  and 
display  output. 
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It  seemed  reasonable  to  add  a  processor  to  the  system 
dedicated  to  the  level  1  control  function.  Track  Data  would  be 
supplied,  as  described  in  Section  4.2.1,  from  the  R  processors, 
while  Flight  Data  would  come  from  the  Bulk  Flight  Data  Processor 
(1^).  Outputs  would  go  to  the  Ie  processor  for  transmission  on 
the  DABS  Data  Link  and  to  the  T  processors  in  the  level  1 
workstations.  It  also  seemed  reasonable  to  process  all  flight 
plans  through  the  route  conversion  process  in  the  processor, 
as  in  the  Baseline  System,  and  to  transmit  the  converted  data  to 
level  1  processing  in  Fc  ,  level  2  processing  in  %  and  the 
Display  Flight  Data  Processor  (Fd),  or  terminal  processing  in  TL  . 
The  processing  and  communication  pattern  for  the  level  2  service, 
then,  is  exactly  preserved  though  reduced  somewhat  in  scope;  the 
level  1  service  is  an  add-on  with  a  minor  change  in  the  output  of 
the  Route  Conversion  Function  to  send  level  1  Flight  Data  to  the 
Automatic  Clearance  Generation  function  in  the  Fc  processor. 

The  addition  of  Automatic  Clearance  Generation  to  the  system 
results  in  a  reduction  in  the  amount  of  processing  to  be  done  in 
the  IL  and  C  processors  despite  the  increase  in  traffic  from  the 
80's  to  the  90 ' s .  The  extent  of  this  change  depended,  of  course, 
on  the  assumption  that  more  than  two-thirds  of  controlled  traffic 
used  level  1  service  (see  Section  3.1.5).  Regardless  of  the 
reason  for  the  relative  loads,  it  is  an  example  of  how  the 
flexibility  of  the  distributed  processing  configuration  can  be 
used  to  adopt  hardware  structure  to  an  evolving  function/ 
software  structure. 

The  controller,  working  the  level  1  sectors  in  the  Future 
System,  will  operate  differently  than  he  would  while  working  a 
level  2  sector.  He  will  use  "management-by-exception",  or  some 
other  acceptable  technique.  Whatever  the  details  of  procedures 
to  be  used,  he  will  require  different  presentations  of 
information  on  his  displays.  If  the  controller  workstation  in 
the  Baseline  System  were  properly  designed,  (i.e.,  if  the  system 
designer  had  correctly  foreseen  the  requirement),  conversion  of 
the  workstation  from  the  Baseline  to  the  level  1  capability  would 
be  simply  a  matter  of  software  changes.  (This  subject  is  also 
discussed  in  the  next  two  sections). 

The  importance  of  the  ICS  to  the  performance  of  the  system 
has  been  stressed  repeatedly  up  to  this  point,  it  is  not  amiss  to 
dwell  on  it  one  more  time.  The  controller  workstations  have  two 
displays,  each  driven  by  a  display  processor,  the  D-position 
Display  Processor  (Dd)  and  the  R-position  Display  Processor  (Dr). 
The  Dr  processor  is  supplied  with  data  to  be  displayed  from  an 
integral  associated  processor,  the  T  processor.  One  can  envision 
Dr  being  connected  to  the  outside  world  only  through  the  T 
processor  (though  this  is  not  necessary,  nor  necessarily 
desirable).  On  the  other  hand,  the  Dd  processors  are  all 
supplied  with  data  to  be  displayed  from  a  common,  Fd  processor, 
which  is  not  part  of  any  of  the  workstations.  The  Dd  processors 
are  connected  to  the  ICS,  then,  in  order  to  communicate  with  Fd. 
There  were  two  reasons  why  a  single  Fd  processor  was  provided  in 


4-13 


the  Baseline  System:  1)  the  duty  cycle/response  time 
requirements  for  the  Flight  Data  processing  were  of  the  order  of 
once  per  five  minutes  per  track,  hence  a  single  processor  could 
handle  nearly  any  conceivable  load  easily,  and  2)  the  inclusion 
of  the  ETABS  equipment,  which  had  this  connectivity  in  the 
Baseline  System,  was  to  be  considered. 

One  would  hope  that  the  ICS  which  forms  the  core  of  the 
Baseline  System  would  be  flexible  and  modular  enough  to  allow  the 
level  1  workstations  to  be  driven  from  the  Fc  processors  in  the 
same  way  that  the  level  2  workstations  are  driven  by  the  Fd 
processor . 

4.2.3  Terminal  Consolidation 

One  provision  of  the  scenario  for  the  Future  System  is  that 
the  functions  of  the  twenty  to  thirty  largest  terminal  areas 
would  be  consolidated  with  the  functions  of  the  en  route  centers 
within  whose  jurisdiction  they  lie.  Given  the  number  of  centers 
and  the  geographical  distributions  of  the  large  terminals,  it  is 
reasonable  to  suppose  that  a  small  center  might  have  no  terminals 
which  qualify  for  consolidation,  a  typical  medium  center  might 
have  one,  and  a  large  center  might  have  two  or  more.  For 
illustrative  purposes,  it  will  be  assumed  that  this  is  the  case. 

The  Functional  Block  Diagram  of  the  Future  System,  Figure 
3.2-1,  shows  that  the  function,  Terminal  Path  Control  (TPC), 
inputs  are  Track  Data  from  the  Track  Data  Data  Base  and  Arrival 
and  Departure  Flight  Plans  from  the  Flight  Data  Data  Base.  It 
has  outputs  in  the  form  of  Advisories  and  Commands  which  are  sent 
to  the  Display  Data  Data  Base  for  display  to  the  controllers  and 
the  Message  Processing  for  output  to  aircraft  via  data  link  if 
and  when  approved  by  the  controllers.  These  are,  of  course,  only 
the  major  inputs  and  outputs;  for  there  are  numerous  control, 
query,  and  response  messages  going  back  and  forth  between  the 
controllers  and  the  Terminal  Path  Control  function. 

There  is  little,  if  any,  interaction  between  the  TPC 
function  and  the  en  route  functions.  This  is  not  surprising 
since  the  terminals  are  controlled  now  by  functions  whose  only 
interaction  is  via  the  set  of  interfacility  messages  (and 
controller  inputs  transmitted  by  voice  link).  In  the  Future 
System,  the  same  kind  of  interaction  will  take  place  via  an 
analogous  set  of  messages;  the  real  new  interaction  is  between 
the  TPC  function  and  Track  Data  and  Flight  Data  Data  Bases,  which 
are  now  common  to  the  en  route  and  terminal  functions. 

The  implementation  of  the  TPC  processing  in  the  Future 
System  may  be  seen  in  Figure  3.3-1.  Since  terminal  processing  is 
so  nearly  independent  of  the  other  functions,  it  makes  sense  to 
assign  it  to  a  separate  processor,  operating  as  independently  as 
possible.  Furthermore,  since  the  terminal  areas  are 
geographically  separated,  even  when  within  the  same  center  area, 
they  are  functionally  almost  completely  independent  of  one 
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another,  so  each  one  could  be  assigned  its  own  processor, 
operating  independently  of  the  others. 


The  terminal  controllers,  like  the  level  1  and  2 
controllers,  can  benefit  from  the  development  of  data 
presentations  which  are  specialized  to  their  own  particular 
needs.  If  the  controller  workstations  are  properly  configured, 
these  special  displays  can  be  provided  by  changes  in  the  software 
(or  firmware)  in  the  T,  Dr  and  Dd  processors.  Note  that,  as  with 
the  level  1  workstations,  data  to  be  displayed  at  the  D-positions 
through  the  Dd  processors  will  come  from  a  different  source  than 
in  the  Baseline  System,  in  this  case,  from  the  TQ  processor 
rather  than  Fd.  Again,  th°  connecting  of  the  ICS  and  its 
flexibility  and  modularity  will  be  crucial. 

4.2.4  Sizing  and  Capacity 

Ideally,  the  distributed  processing  system  would  consist  of 
a  set  of  similar  sized  tasks  with  clearly  defined,  moderate, 
inter-task  communications  requirements.  These  tasks  could  then 
be  assigned  to  a  set  of  identical  processors,  each  capable  of 
performing  one  of  the  tasks;  and  the  processors  could  be 
connected  by  a  communications  system,  capable  of  handling  the 
interprocessor  message  load. 

Under  the  "hardware  overkill"  hypothesis,  the  standard 
processor  would  be  chosen  to  be  so  capable  and  with  so  much 
memory  that  no  indivisible  task  would  be  too  big  for  it.  If, 
then,  each  processor  were  connected  to  every  other  by  a  very  high 
bandwidth  link,  the  hardware  aspects  of  the  design  problems  would 
simply  disappear.  Even  if  this  turns  out  to  be  a  valid 
procedure,  investigating  the  processing  requirements  of  the  ATC 
would  be  worthwhile,  if  only  to  understand  its  operation  better. 

The  numbers  used  in  the  computations  of  the  processing 
requirements  for  the  Baseline  System  and  the  Future  System  were 
based  on  estimates  of  peak  traffic  loads  in  1985  and  1995.  The 
formulas  were  based  on  estimates  of  relative  computational 
complexity  of  the  various  functions  performed  by  the  system.  The 
final  outputs  of  Comparitive  Processing  Numbers  and 
Communications  Channel  Requirements  for  the  Baseline  and  Future 
Systems  are  given  in  Tables  2.3-2,  2.3-3,  3.3-2  and  3.3-3.  They 
are  not  meant  to  be  used  to  select  a  processor  for  a  particular 
task;  obviously  they  are  not  suited  to  that.  They  are  to  be  used 
to  compare  1)  the  ranges  of  requirements  within  a  center  and 
among  small,  medium,  and  large  centers,  and  to  compare  2)  the 
changes  in  requirements  in  going  from  the  Baseline  to  the  Future 
System. 

There  are  three  ways  in  which  the  variation  in  CPNs  may  be 
viewed:  within  a  center,  from  center-to-center  and  across  time, 
from  Baseline  to  Future  System.  The  following  observations  may 
be  made: 
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a)  The  widest  variation  in  Comparative  Processing  Number 
occurs  when  comparing  numbers  for  different  processors 
within  a  center  of  a  given  size  and  a  given  timeframe. 
The  ratios  of  the  largest  CPN  to  the  smallest  range 
from  nearly  50  to  over  150.  There  is  a  wide  variation 
in  the  communications  requirements  of  various 
processors  within  a  given  center  as  well. 

b)  The  variation  of  CPNs  within  either  the  Baseline  or 
Future  System  in  going  from  a  small  to  a  large  center 
for  the  same  processor  is  much  smaller.  In  both 
systems,  the  ratio  of  the  CPN  for  any  one  processor  in 
a  large  center  to  the  CPN  of  the  same  processor  in  a 
small  center  ranges  from  1  to  less  than  4.5  in  both  the 
Baseline  and  the  Future  Systems.  The  communications 
requirements  show  the  same  kind  of  moderate  increase, 
either  no  change  in  channel  type  or  a  move  to  the  next 
larger  type. 

c)  The  ratios  between  CPNs  of  processors  of  the  same  kind 
at  similarly  sized  centers  in  going  from  the  Baseline 
to  the  Future  Systems  show  no  such  trend;  some  of  them 
are  less  than  one  third  and  some  greater  than  three. 

The  communications  channel  requirements  also  fail  to 
show  a  trend;  some  of  them  increase  and  others 
decrease. 

The  within  center  variation  in  the  CPN  is  obviously  a 
function  of  the  design  of  the  system,  in  particular,  the 
partitioning  of  the  functions  and  their  assignment  to  the  various 
processors.  The  lower  bound  on  the  size  of  the  most  capable 
processor  is  given  by  the  size  of  the  largest  indivisible  task; 
the  size  of  the  least  capable  processor  might  approach  zero.  In 
the  Baseline  System,  the  largest  processors  are  the  C  and  T 
processors,  the  former  because  it  has  a  large  number  of 
computations  to  do  in  a  moderate  amount  of  time,  and  the  latter 
because  it  has  a  modest  number  of  computations  in  a  very  short 
time. 


If  the  processor  is  dismissed  as  a  trivial  driver  of  an 
alphanumeric  display,  then  the  ratio  of  processing  requirements 
within  each  Baseline  center  is  about  15.  If  all  processors, 
except  perhaps  were  identical,  then  more  than  half  of  them 
would  be  oversized  by  a  factor  of  four  or  more,  not  including 
factors  for  peaking  and  expansion.  (That  is,  for  comparison 
purposes  only,  the  processing  requirements  have  been  considered. 
In  order  to  actually  size  the  processors,  one  would  have  to 
account  for  the  fact  that  the  processors  should  run  at  less  than 
50%  of  capacity  in  order  to  be  able  to  handle  peaks  in  non- 
uniform  demands.  One  would  also  want  to  provide  additional 
capacity  to  allow  for  increase  in  traffic  over  the  life  of  the 
system.  Since  these  factors  would  be  applied  to  all  of  the 
processors,  they  may  be,  and  have  been,  suppressed  in  this 
study) . 
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Furthermore,  if  identical  processors  are  to  be  used  in  all 
of  the  centers,  large  and  small,  then  an  additional  factor  of  two 
would  be  introduced  at  the  small  centers.  Half  of  the  processors 
in  the  small  center  would  have  an  order  of  magnitude  more 
capacity  than  required. 

Suppose  then  that  this  imbalance  was  acceptable,  that  the 
hardware  costs  could  be  shown  to  be  such  a  small  part  of  the  life 
cycle  costs  that  the  advantages  of  having  a  single  type  of 
processor  far  outweigh  the  possible  extra  cost.  How  much  change 
will  be  necessary  in  going  from  the  Baseline  to  the  Future 
System?  A  comparison  of  the  CPNs  of  the  two  systems  shows  that 
there  is  surprisingly  little  increase  given  and  that  the  traffic 
load  on  which  the  calculations  were  based  is  larger.  As  a  matter 
of  fact,  many  processors  have  much  lower  CPNs.  The  answer,  of 
course,  is  that  the  processing  load  has  been  redistributed. 
Tracking  has  been  moved  to  the  DABS  processors,  processing  of 
level  1  traffic  has  been  concentrated  in  the  new  Automatic 
Clearance  Delivery  processors,  and  sensor  data  processing  has 
been  moved  to  the  External  Interface  processor.  New  processing 
load  in  the  form  of  Terminal  Path  Control  is  assigned  to  new  T 
processors.  There  seems  to  be  no  problem  of  processing  power. p 
Of  the  three  places  in  the  Future  System  which  have  large 
requirements,  two,  Fc  and  T  are  new  processors  which  could  be 
implemented  with  new  technology  in  the  1990 's,  while  the  third, 

I  ,  is  assigned  a  function  that  is  easily  divided  among  a  number 
of  processors. 

As  far  as  interprocessor  communications  is  concerned,  a 
simple  summation  of  the  peak  rates  into  or  out  of  all  of  the 
processors  of  the  largest  center  in  the  Future  System  gives  a 
maximum  required  capacity  of  approximately  100K  bytes/sec.  In 
other  words,  the  ATC  system  is  not  particularly  demanding  as  far 
as  interprocessor  communications  rate  is  concerned,  although 
other  factors,  such  as  synchronization  and  reliability  remain  as 
initial  design  issues. 

In  summary,  the  distributed  processing  configuration  studied 
here  seems  1)  to  be  a  reasonably  flexible  way  of  providing  the 
processing  capability  in  an  ATC  system,  and  2)  to  be  a  system 
which  can  be  easily  modified  to  meet  new  requirements. 

4.3  SUMMARY  AND  CONCLUSIONS 

This  study  attempted  to  find  the  answer  to  the  question, 
"What  will  be  the  effect  in  the  1990 's  of  having  chosen  a 
distributed  processing  concept  to  replace  the  current  en  route 
ATC  computers?"  Subject  to  certain  qualifications  and  caveats, 
the  answer  determined  here  is  that  the  distributed  processing 
concept  is  ideally  suited  for  the  ATC  system  of  the  1980 's,  and, 
when  the  system  is  to  be  modified  in  the  1990 's,  it  will  provide 
a  reasonable  basis  on  which  to  build  a  new  system. 


The  following  statements  summarize  the  conclusions  drawn 
from  this  study: 

1)  The  structure  of  the  hardware  of  a  system  should  be 
matched  closely  to  the  structure  of  the  software  of  the 
system,  which  should  have  been  matched  to  the  structure 
of  the  functional  requirements  of  the  system.  A 
distributed  processing  configuration  may  be  designed 
which  matches  closely  the  structure  of  the  software  of 
the  ATC  system.  Furthermore,  the  configuration  may  be 
easily  modified  to  match  changes  in  the  software 
structure  as  functional  requirements  change. 

2)  The  state  of  support  software  for  distributed  systems 
is  at  present,  somewhat  uncertain,  but  there  is  a  great 
deal  of  research  underway  in  such  areas  as  high-order 
languages  for  distributed  processing  and  distributed 
operating  systems. 

3)  Many  ATC  system  changes  will  consist  of  new,  virtually 
independent,  functions  to  be  added  to  the  system.  The 
form  of  the  distributed  processing  configuration  will 
make  it  especially  convenient  to  add  functions  of  this 
type  by  implementing  them  on  new  independent 
processors. 

4)  While  memory  and  processors,  already  part  of  the 
system,  might  be  difficult  to  reassign  to  new  functions 
in  some  cases  because  of  their  size,  new  components  of 
higher  capacity  and/or  new  technology  could  be 
substituted  or  added.  A  systematic  program  of 
upgrading  the  system  for  added  capacity  could  be  worked 
out,  replacing  1/nth  of  the  system  each  year  for  n 
years. 

5)  A  standard  controller  workstation  could  be  developed 
which  would  contain  displays,  display  drivers,  input 
devices,  and  enough  processing  and  memory  capacity  to 
make  it  capable  of  serving  a  variety  of  controller 
positions. 

6)  The  variations  in  the  sizes  of  processors  needed  in  a 
distributed  ATC  system  seem  to  be  caused  more  by  design 
decisions  in  the  assignment  of  functions  to  processors 
than  by  load  variations  from  center  to  center  or  with 
time.  The  flexibility  of  the  distributed  concept 
should  make  relatively  easy  the  balancing  of  the  system 
load  as  new  requirements  cause  the  system  to  be 

mod i f i ed . 

7)  The  real  key  to  the  performance  of  a  distributed 
processing  system  is  the  capability  of  the 
Interprocessor  Communications  Subsystem.  Although 
bandwidth  requirements  will  be  quite  modest,  the 


synchronization  of  the  component  processes  and  the 
attainment  of  various  system  response  time  requirements 
will  depend  on  how  well  the  ICS  is  conceived  and 
implemented. 

8)  The  feasibility  of  any  particular  system  modification 
will  depend  on  the  flexibility  and  modularity  of  the 
ICS  and  on  whether  it  can  be  modified  to  handle  the  new 
pattern  of  message  traffic.  If  the  addressing/access 
scheme  is  not  suitable,  a  serious  problem  could  arise 
in  making  the  modification. 

9)  The  dynamic  behavior  of  the  modified  system  should  be 
of  concern;  there  is  no  certainty  that  a  well  behaved 
system  will  retain  its  good  qualities  when  modified. 

10)  The  reliability  and  error  tolerance  of  distributed 
systems  is  not  yet  understood.  Many  ad  hoc  solutions 
exist,  but  this  is  an  area  in  which  much  work  needs  to 
be  done. 
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APPENDIX  A 


SCENARIO  FOR  1995 


A. 1  INTRODUCTION 

FAA  is  in  the  process  of  establishing  and  analyzing  the  ATC 
computer  requirements  for  the  1980 's  and  1990's.  It  is  evident 
the  the  en  route  computers  need  replacement  if  the  projected 
traffic  and  functional  growth  is  to  be  accommodated.  While  the 
transition  and  acquisition  strategies  for  a  new  system  have  not 
been  selected,  it  is  reasonable  to  assume  that  deployment  of  a 
new  en  route  computer  will  begin  in  the  late  1980' s.  That 
computer  system,  when  first  installed,  will  perform  the  functions 
being  performed  today;  e.g.,  DARC,  ETABS,  and  those  new  functions 
that  are  currently  being  developed  for  the  9020®  computers. 

This  new  baseline  ARTCC  computer  system,  once  in  place,  will 
provide  the  vehicle  for  evolution  to  the  much  more  highly 
automated  ATC  system. 

In  FY-79  and  FY-80  the  Transportation  Systems  Center  (TSC) 
is  examining  how  well  different  compiitit  architectures  can  handle 
such  ATC  evolution.  The  approach  taken  was  to  map  a  Baseline 
System  onto  different  architectures  and  to  analyze  the  extension 
of  each  of  these  mappings  to  a  fairly  optimistic  future  (1995) 
scenario. 

The  following  scenario  was  prepared  jointly  by  the  Office  of 
Systems  Engineering  Management  (OSEM)  and  TSC  for  this  analysis. 
It  incorporates  many  of  the  ideas  discussed  within  the  AED  and 
ATF  complexes,  but  should,  in  no  way,  be  interpreted  as  a 
statement  of  FAA  long  term  requirements. 

This  strawman  does  reflect  the  general  direction  in  which 
the  ATC  system  is  expected  to  evolve  and  thus  is  well  suited  to 
the  TSC  analysis. 

The  scenario  represents  a  significant  functional  step 
forward  from  the  baseline  rather  than  a  realistic  projection  for 
the  specific  year  1995.  Furthermore,  there  is  no  implication 
that  the  scenario  is  to  be  implemented  as  a  single  upgrade  from 
the  baseline. 

A. 2  AIRSPACE  STRUCTURE 

A. 2.1  Levels  of  Service 

There  will  be  five  levels  of  en  route  ATC  service  and/or 
airspace  regulation.  Note  that  ATC  is  imposed  only  on  the  top 
two  levels  and  that  surveillance  is  maintained  only  over  the  top 
three. 
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Level  1  Highly  automated,  positive  control;  central,  ground- 
controlled  separation  and  flow  management;  direct 
routing  allowed. 

Level  2  Similar  to  current  operations  — computer-aided,  manual 
separation  and  flow  management;  positive  control; 
direct  routing  allowed. 

Level  3  Outside  of  control  area  but  within  the  DABS 
surveillance;  ATARS  provides  separation. 

Level  4  Avionics  required  (transponder,  BCAS). 

Level  5  No  services,  no  requirements. 

A. 2. 2  Description  of  Structure 

The  airspace  will  be  structured  so  that  positive  control 
will  be  exerted  where  traffic  is  heavy,  while  maximum  freedom 
will  be  allowed  where  traffic  is  light.  Specifically: 

a.  Level  1  service  will  be  supplied  in  all  airspace  over 
18,000  ft  and  airspace  over  12,000  ft  within  60  miles  of 
designated  terminals. 

b.  Level  2  service  will  be  supplied  in  the  remaining 
airspace  over  12,000  ft  and  en  route  airspace  below  12,000  ft 
that  is  within  30  miles  of  the  designated  terminals. 

c.  Level  3  service  will  be  supplied  over  the  remaining  en 
route  area  between  5,000  ft  and  12,000  ft  where  there  is 
significant  traffic. 

d.  Level  4  and  5  en  route  service  will  be  supplied 
elsewhere. 

A. 2. 3  Terminal  Areas 

Radar  control  (arrival,  departure,  and  transition)  for  all 
terminal  radar  facilities  within  the  20-30  largest  terminal 
regions  will  be  integrated  into  the  en  route  facility  within 
whose  jurisdiction  the  terminal  region  lies.  Other  terminal 
radar  facilities  will  remain  relatively  unchanged.  The  basic 
terminal  control  philosophy  in  these  integrated  facilities  will 
not  change.  Pilots  will  notice  a  difference,  because  integration 
of  control  will  permit  a  suitable  sector ization  within  the 
affected  regions. 
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A. 3  SURVEILLANCE  AND  COMMUNICATIONS 


A. 3.1  Aircraft  Surveillance  and  Data  Dissemination 

A.  3. 1.1  En  Route  Survei 1 lance  -  All  secondary  radars  are  DABS 
with  4  to  6-second  update  rates,  and  all  areas  under  levels  1,  2, 
and  3  will  be  covered. 

A.  3. 1.2  Terminal  Surveillance  -  There  will  be  some  terminal 
primary  radar.  All  terminal  secondary  radars  will  be  DABS. 

A.  3 . 1 . 3  General 

All  surveillance  systems  will  be  netted  with  adjacent  sensor 
sites  backing  up  one  another.  Each  ATC  facility  will  be 
connected  to  this  surveillance  network  and  will,  therefore,  be 
able  to  obtain  surveillance  information  from  any  sensor.  The 
DABS  sensors,  through  the  surveillance  network,  will  assure 
coverage  continuity.  Each  sensor  site  will  be  responsible  for  a 
fixed  geographic  region  and  will  provide  target  reports  for 
distribution  over  the  network  for  all  aircraft  in  the  region. 

The  sites  will,  when  necessary,  make  use  of  information  from 
adjacent  centers  to  improve  the  quality  of  the  target  reports. 
Target  reports  will  contain  unique  DABS  ID  codes,  thereby 
eliminating  the  need  for  the  target/track  correlation  function  at 
the  user  ATC  facilities  (except  for  primary  returns  with  no 
beacon  information).  Slant-range  correction  and  Re/XY  coordinate 
conversion  will  be  performed  by  the  DABS  site  processors.  Target 
reports  will  be  in  the  sensor  coordinate  system. 

A. 3. 2  Weather  Surveillance  and  Data  Dissemination 

FAA  will  get  weather  data  from  the  National  Weather  Service 
(NWS)  network  in  the  form  of  contours  and  flow  patterns.  This 
will  be  augmented  by  winds  aloft  data  provided  by  aircraft  via 
the  data  link.  There  will  be  a  weather  controller 
(meteorologist)  at  each  center  who  reviews  the  information  and 
annotates  it.  The  information  will  be  distributed  to  the 
controller  (selectively)  and  to  AERA.  In  the  high  density 
terminal  areas,  FAA  radars  will  be  modified  to  have  Doppler 
processing  systems  to  provide  data  to  the  ATC  computers. 

A.  3 . 3  Avionics 

A. 3. 3.1  General  -  The  avionics  for  1995  will  be  configured  to 
operate  with  the  DABS  and  its  associated  Data  Link  (DL).  The 
avionics  is  to  provide  both  uplink  reception  and  downlink 
transmission  of  surveillance  and  communication  messages  in  a 
digital  Time  Division  Multiple  Access  (TDMA)  format  as  described 
in  the  DABS  Engineering  Requirements  (ER)  report.  The  transition 
capacity  of  the  data  link  is  structured  around  the  600  DABS 


periods  (of  4.2  ms)  per  scan,  resulting  in  16,800  transactions  of 
about  170  bits  each  (2.8  million  bits)  per  scan.* 


A. 3. 3. 2  Services  Provided  (Future)  -  Surveillance  is  provided  to 
all  aircraft.  ATC  services  (tactical)  are  provided  to  Instrument 
Flight  Rules  ( IFR)  and  Visual  Flight  Rules  ( VFR)  A/C  (about  45% 
of  fleet).  DL  requirement  is  about  0.03  Comm-A  message  (5  bits) 
per  A/C  per  scan. 


ATARS  and  Cockpit  Display  Traffic  Indicator  (CDTI)  are 
provided  to  an  undetermined  number  of  IFR  and  other  A/C  (20-40% 
of  fleet).  DL  requirement  is  between  1-14  messages  (170-2700 
bits)  per  A/C  per  scan. 

Real-time  automatic  weather  delivery  is  provided  to  all 
aircraft.  DL  requirement  is  about  .03  Comm-A  message  (5  bits) 
per  A/C  per  scan. 

Record  messages  (less  time  critical,  e.g.  flight  plan 
revision,  ATIS,  weather)  are  provided  to  all  aircraft.  The  DL 
requirement  is  0.10  Comm-A  message  (17  bits)  per  GA  A/C  and  0.42 
Comm-A  message  (71  bits)  per  air  carrier  A/C  per  scan. 

Ground  data  is  uplinked  to  all  aircraft.  The  DL  requirement 
is  0.5  Comm-A  message  (84  bits)  per  A/C  per  scan. 

Downlink  of  airborne  data  is  provided  from  all  aircraft. 

The  DL  requirement  is  the  same  as  for  uplink  (84  bits). 

A. 3. 3. 3  Adequacy  and  Projected  Performance  -  Provision  of 
services  indicated  represents  a  demand  equivalent  of  four 
transactions  (640  bits)  per  aircraft  per  scan  (LAX  1995  model). 
Accounting  for  an  estimated  round  reliability  of  90%  results  in  a 
requirement  for  4.4  transactions  per  A/C  per  scan.  This  4.4 
transactions  per  A/C  demand  is  about  80%  of  the  capacity  (5.4) 
for  an  eight  sensor  configuration  operating  in  the  LA  basin  1995 
model . 

The  estimates  may  be  conservatively  high  since  DABS  round 
reliability  should  be  much  better  than  90%.  Not  all  A/C  in  1995 
may  be  equipped  with  DABS  or  with  cockpit  devices  which  allow  the 
use  of  DL  services.  Traffic  growth  may  be  less  than  the  LA  basin 
1995  model  estimates. 


*If  the  DABS  sensor  services  400  aircraft  (a/c),  it  has  a 
theoretical  capacity  of  42  Comm-A  transactions  per  aircraft  per 
scan.  Under  projected  conditions,  (i.e.  Los  Angeles 
International  Airport  (LAX)  1995  model),  this  may  be  reduced  to 
between  5-10  Comm-A  transactions  per  A/C  per  scan  because  of  the 
distribution,  or  bunching  of  A/C  in  the  sensor  beam  width.  The 
most  severe  azimuth  bunching  would  be  14  aircraft  in  a  2.4  degree 
beam  width,  all  within  48  n.  mi.  of  the  sensor  serving  them. 
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The  DABS  Data  Link  can  handle  all  services  postulated,  while 
limiting  interference  with  ATCRBS  to  an  acceptable  level.  Much 
more  use  of  ATC  automation  services  than  indicated  could  be 
provided  with  little  impact  on  capacity. 

A. 4  CONTROL  STRUCTURE 

A. 4.1  Facility  Hierarchy 

There  will  be  a  single,  central  traffic  management  facility, 
similar  to  the  present  Central  Flow  Control  Facility,  which  will 
exchange  control  information  with  the  en  route  centers.  There 
will  be  20  en  route  centers  as  there  are  now,  but  the  number  of 
terminal  approach/departure  control  facilities  will  be 
drastically  reduced  by  the  absorption  of  the  busiest  20-30  into 
the  corresponding  en  route  facilities.  Tower  facilities  will 
remain  as  at  present. 

A. 4. 1.1  Central  Facility  -  The  central  facility  will  communicate 
with  all  of  the  centers  via  a  common  data  communications  network. 

A. 4. 1.2  En  Route  Centers  -  Each  of  the  centers  will  be  able  to 
communicate  with  all  others  via  the  common  data  network  (although 
they  would  normally  communicate  only  with  adjacent  centers).  The 
centers  will  be  alike  functionally,  differing  only  with  respect 
to  capacity. 

The  consolidation  of  terminal  and  en  route  control,  where  it 
is  accomplished,  will  be  complete;  all  approach  and  departure 
control  within  a  terminal  area  will  be  included,  and  a  common 
radar  data  base  will  be  used  for  both  en  route  and  terminal 
control . 

A. 4. 1.3  Terminal  Facilities  -  Those  terminal  facilities  not 
absorbed  into  the  en  route  centers  will  continue  to  operate  much 
as  they  do  now.  Terminal  facilities  will  communicate  with  en 
route  centers  via  the  common  data  network. 

A. 4. 1.4  Tower  Facilities  -  Within  the  integrated  terminal 
regions: 

a.  Towers  will  be  supplied  with  remotely  driven  displays 
using  digital  information  from  the  en  route  centers. 

b.  Tower  automation  systems  will  exchange  information  with 
the  centers  via  the  common  data  communications  network. 


A. 4. 2  Integrated  Flow  Management 

There  will  be  a  three-level  integrated  flow  management 
system  incorporating  Central  Flow  Control,  En  Route  Flow  Control, 
and  Terminal  Flow  Control . 


A. 4. 2.1  Central  Flow  Control  -  The  Central  Flow  Control  function 
will  manage  the  flow  of  traffic  on  a  nationwide  basis,  attempting 
to  eliminate  airborne  delays  for  flights  into  high-density 
terminals. 

Central  Flow  Control  will  be  connected  to  the  ARTCCs  so  that 
it  can  receive  messages  concerning  current  operations  (actual 
departure,  flight  plan  amendments,  etc.)  and  transmit  flow 
control  messages  (departure  delays,  etc.). 

A. 4. 2. 2  En  Route  Flow  Control  -  The  En  Route  Flow  Control 
Function  will  attempt  to  minimize  airborne  delays  and  inefficient 
flight  profiles,  such  as  low-altitude  holding,  by  speed  and  path 
control  over  the  center  area  and,  over  the  areas  of  adjacent 
centers  (with  their  cooperation). 

Information  gathered  in  the  terminal  areas  (acceptance 
rates,  weather)  will  be  collected  in  the  ARTCC  for  use  there  and 
for  transmittal  to  the  Central  Facility. 

This  function,  in  coordination  with  the  AERA  function,  will 
act  to  restructure  the  traffic  flow  over  the  center  area  when 
required  by  weather  changes  or  changes  in  airport  capacities. 

A. 4. 2. 3  Terminal  Flow  Control  -  Terminal  Flow  Control  will  be 
composed  of  two  parts: 

a.  The  planning  function  and  the  flow  function  (see  also, 
Section  A. 4. 3. 4) . 

b.  The  planning  function  will  derive  information  about  the 
operation  of  the  terminal  and  supply  it  to  the  central 
and  en  route  flow  control  functions  as  needed. 

c.  The  flow  function  will  act  as  an  automatic  metering  and 
spacing  mechanism  to  ensure  the  arrival  of  traffic  at 
the  runway  threshold  at  the  correct  times. 

A. 4. 3  New  Functions 

A. 4. 3.1  AERA  and  Traffic  Management  -  The  present  separate 
functions  and/or  concepts  of  conflict  detection  and  resolution, 
MSAW,  en  route  metering,  terminal  metering  and  spacing,  flight 
plan  probe,  and  AERA  will  be  integrated  into  a  single  functional 
subsystem  which  will  generate  conflict  free  profiles  and 
clearances  for  traffic  operating  in  positive  control  airspace. 

This  function  will  hand  off  traffic  either  to  the  local 
controller  at  the  busy  terminals,  or  to  the  approach  controller 
at  the  terminals  which  retain  approach/departure  control. 

A. 4. 3. 2  FSS  Flight  Plan  Preprocessing  -  Flight  plans  submitted 
through  FSS  will  be  transmitted  to  the  ARTCC  (over  a  direct  data 
line  or  data  communications  network).  Format,  syntax,  and 


legality  checks  will  already  have  been  performed. 


A. 4. 3. 3  Weather  Services  -  Weather  information  will  be  available 
to  the  system  from  two  sources:  the  NWS  computer  and  from  Doppler 
weather  radars  (see  Section  A. 3. 2). 

The  en  route  computer  complex  will  process  both  kinds  of 
weather  information,  making  them  available  to  both  automated  and 
non-automated  parts  of  the  system.  That  is,  data  such  as  winds 
aloft  and  contours  of  severe  weather  will  be  available  to  the 
AERA  and  Integrated  Flow  Management  function  (see  Section 
A. 4. 3.1)  for  path  prediction  and  hazard  warnings.  Weather 
contours  and  selectable  data  read-outs  will  be  available  as  well 
on  the  displays  of  the  ATC  Specialists. 

A. 4. 3. 4  Terminal  Functions  -  Approach  and  departure  control 
functions  for  the  20-30  busiest  terminals  areas  will  be 
integrated  into  the  en  route  system.  Control  functions  in  these 
terminal  areas  will  be  similar  to  today's  with  the  addition  of 
automated  metering  and  spacing  (see  Section  A.4.3.1).  These 
functions  will  be  combined  with  the  en  route  functions  to  produce 
a  unified  control  system  (as  opposed  to  being  a  mere  translation 
of  the  present  terminal  system  onto  the  en  route  computer.) 

Since  the  system  will  be  integrated,  a  common  radar  data  base 
will  be  available  for  use  throughout  the  center's  area,  including 
the  terminal  areas.  The  Terminal  Information  Processing  System 
(TIPS)  functions  will  be  fully  supported,  including  services  in 
the  major  and  remote  satellite  towers. 

A. 4. 4  Backups 

Automated  functions  in  the  en  route  system  will  be  fully 
backed  up  at  other  centers.  A  failed  center  will  be  divided 
geographically  so  that  each  adjacent  center  can  take  over 
responsibility  for  a  portion  of  the  failed  center's  airspace. 

The  specific  mechanism  for  carrying  out  the  back-up  function  has 
not  yet  been  determined. 

(For  purposes  of  studying  the  capability  for  evolution  of 
different  replacement  computer  architectures,  the  above 
characterization  is  adequate  to  account  for  additional 
communication  loads,  processing  requirements,  and  memory 
requirements. ) 

A. 4. 5  Controller/Automation  Interface 

Clearly  the  role  of  the  ATC  specialist  will  change 
considerably  as  automated  decision  making  is  introduced.  As  a 
result,  the  physical  man/machine  interface  and  the  type  data  and 
data  flow  between  man  and  machine  will  likely  be  different  from 
what  it  is  today.  Because  of  the  great  uncertainty  about  what 
this  interface  should  be,  no  postulation  will  be  made  in  this 
scenario.  For  purposes  of  the  analysis,  it  will  be  assumed  that 
automated  decision  making  will  be  introduced. 
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A. 5  LOADING 


Loading  figures  for  representative  centers  (small,  medium, 
and  large  for  1975  have  been  obtained  from  published  FAA  sources 
(Ref.  1,  2).  Estimates  for  1985  have  been  obtained  from  an 
additional  source  (Ref.  3).  These  numbers  have  been  used  to 
develop  sizing  estimates  for  the  so-called  H Baseline *  System. 

It  will  be  assumed  that  traffic  will  increase  during  the 
1985-1995  period  linearly  at  the  same  rate  as  for  1985-1990  given 
in  Reference  3. 
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APPENDIX  B 


METHODOLOGY  FOR  ESTIMATING  ARTCC  LOADING  DATA 
FOR  FORECAST  YEARS  1985  AND  1995 
B.l  INTRODUCTION 

The  basic  objective  in  developing  center  loading  data  was  to 
estimate  the  range  of  loads  that  the  1985  Baseline  CCC  must  be 
designed  to  operate  under  and  the  increased  loads  that  the 
enhanced  Baseline  CCC  can  be  expected  to  encounter  in  1995.  1975 

was  chosen  as  the  base  year  from  which  these  projections  were 
made  because  of  the  availability  of  historical  data  and  because 
it  seemed  reasonable  to  work  with  10-year  intervals  preceding  and 
following  the  1985  Baseline  System  date.  Loads  representative  of 
high,  medium,  and  low  density  en  route  centers  were  developed  on 
the  basis  of  the  rankings  of  20  Continental  United  States  (CONUS) 
centers  with  respect  to  total  IFR  flights  handled  annually. 
Chicago,  Memphis,  and  Denver  were  the  centers  that  proved  to  be 
representative  of  high,  medium,  and  low  density,  respectively. 

This  appendix  first  describes  how  the  available  1975  air 
traffic  activity  data  was  analyzed  to  develop  proportionalities, 
peaking  factors,  peak  instantaneous  aircraft,  and  flight  plan 
counts.  It  then  describes  how  the  latter  were  used  to  review  FAA 
aviation  forecasts  and  thereby  estimate  loading  data  for  1985  and 
1995. 


B.2  ANALYSIS  OF  1975  AIR  TRAFFIC  ACTIVITY  DATA 
B.2.1  Flights  Handled 

The  process  of  analyzing  1975  data  begins  with  an 
examination  of  Table  B-l.  The  first  step  was  to  deduce  from 
Table  B-l  the  non-CONUS  center  "departures"  and  "overs"  from  the 
totals  as  shown  below. 


TABLE  B-l  RANK  ORDER  OF  FAA  ARTCCs  BY  IFR  AIRCRAFT  HANDLED 

AND  BY  IFR  DEPARTURES  AND  OVERS:  FISCAL  YEAR  1975 


CENTER 

AIRCRAFT  HANDLED 

DEPARTURE 

OVER 

RANK 

NUMBER 

RANK 

NUMBER 

RANK 

number 

Total  . . 

— 

23.585,999 

-- 

9,258,198 

— 

5,069,603 

Chicago,  Illinois  .. 

1 

1,724,441 

1 

757,296 

13 

209,849 

Cleveland,  Ohio  .... 

2 

1,655,816 

3 

606,716 

1 

442,384 

New  York,  New  York  . 

3 

1,533,078 

2 

649,095 

10 

234,888 

Atlanta,  Georgia  ... 

4 

1,383,014 

4 

562,586 

7 

257,842 

Washington,  D.C.  ... 

5 

1 , 378 , 370 

6 

53“ ,795 

5 

308,780 

Indana polls,  Ind.  .. 

6 

1,316,443 

9 

““5,977 

3 

424,489 

Fort  Worth,  Texas  .. 

7 

1,305,953 

5 

546,726 

12 

212,501 

Memphis,  Tenn.  ..... 

8 

1, 138,53“ 

12 

“04,315 

4 

329,90“ 

Los  Angeles,  Calif.. 

9 

1.092,133 

7 

507,793 

21 

76,547 

Jacksonville,  Calif. 

10 

1,089,248 

16 

328,58“ 

2 

“32,080 

Kansas  City,  Mo.  ... 

11 

1,079,663 

11 

“11,301 

8 

257,061 

Houston,  Texas  ..... 

12 

1,046,545 

8 

455,481 

17 

135,583 

Miami,  Florida  . 

13 

1,024,853 

10 

“30,270 

16 

164,313 

Minneapolis,  Minn.  . 

14 

1,011,297 

14 

391,147 

11 

229,003 

Boston,  Mass . 

15 

917,781 

15 

368,406 

14 

180,969 

Oakland,  Calif . 

16 

890,893 

13 

392,83“ 

18 

105,225 

Albuquerque,  N.  Hex. 

17 

875,362 

18 

311,105 

9 

253,152 

Denver,  Colorado  ... 

18 

696,778 

19 

217,390 

6 

261,998 

Seattle,  Wash.  ..... 

19 

670,501 

17 

317,792 

24 

3“,917 

Salt  Lake  City,  Utah 

20 

448,918 

21 

136,98“ 

15 

174,950 

Honolulu,  Hawaii  ... 

21 

386,585 

20 

150,923 

20 

84,739 

Anchorage,  Alaska  .. 

22 

279,714 

22 

121,665 

23 

36,38“ 

San  Juan,  P.R.  ..... 

23 

251,230 

23 

76,939 

19 

97,352 

Great  Falls,  Mont.  . 

24 

193,999 

24 

67,210 

22 

59.579 

Balboa,  Canal  Zone  . 

25 

79,861 

25 

24,045 

25 

31,771 

Guam  ............... 

26 

71,884 

26 

21,326 

26 

29,232 

Fairbanks,  Alaska  .. 

27 

“3,105 

27 

19,“97 

27 

4,111 

bource : 


"FAA  Air  Traffic  Activity,  Fiscal  Year  1975"  U.S.  DOT 
FAA,  Information  and  Statistics  Division,  Office  of 
Management  Systems. 


Non-CONUS 

Center 

Aircraft  Handled 

Departures 

Overs 

Honolulu 

386,585 

150,923 

84,739 

Anchorage 

279,714 

121,665 

36,384 

San  Juan 

251,230 

76,939 

97,352 

Balboa 

79,861 

24,045 

31,771 

Guam 

71,884 

21,326 

29,232 

Fairbanks 

43,105 

19,497 

4.111 

1,112,379 

414,395 

283,589 

Percent  of 

Total  4.7 

4.5 

5.6 

The  numbers  for  the  now  extinct  Great  Falls  center  were 
added  to  those  of  the  Salt  Lake  City  center  (which  subsequently 
absorbed  it  a  year  or  so  later),  and  a  new  table.  Table  B-2,  was 
prepared  with  Conus  center  numbers  only.  Each  center's 
percentage  of  departures  and  overs  was  calculated;  annual  counts 
of  flights,  departures,  and  overs  were  converted  to  average  day 
counts  by  dividing  by  365. 

Peak  day  1975  counts  were  then  obtained  from  ”En  Route  IFR 
Air  Traffic  Survey  Peak  Day  -  Fiscal  Year  1975,"  published  by  the 
FAA's  Office  of  Management  Systems.  The  busy  hour  and  total 
departures  on  the  peak  day  for  each  center  were  extracted  from 
the  survey  and  entered  in  Table  B-2  along  with  their  average  day 
counterparts.  For  each  center,  the  peaking  factors  for  peak  day 
were  derived  by  calculating  the  ratio  of  total  departures-peak 
day  to  total  departures-average  day;  the  peaking  factor  for  busy 
hour-peak  day  was  obtained  by  calculating  the  ratio  of  busy  hour 
departures-peak  day  to  total  departures-peak  day.  The  use  of 
these  factors  is  described  later  during  the  procedure  for 
estimating  1985  and  1995  data. 

B. 2.2  Flight  Plans  Filed 

Since  "FAA  Air  Traffic  Activity  Fiscal  Year  1975"  provides  a 
breakout  (Table  15)  of  flight  plans  originating  from  flight 
service  stations  grouped  by  state  rather  than  by  center,  it  was 
necessary  to  reorganize  the  data  by  assigning  flight  service 
stations  to  their  associated  centers.  Table  B-3  contains  the 
data  resulting  from  this  effort.  The  number  of  flight  plans  on 
an  average  day  was  obtained  by  dividing  by  365.  Busy  hour- 
average  day,  peak  day,  and  busy  hour-peak  day  were  obtained  by 
multiplying  average  day  counts  by  the  busy  hour  and  peak  day 
factors . 
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TABLE  B-3  FLIGHT  PLANS  ORIGINATING  AT  FLIGHT  SERVICE 
STATIONS  IN  1975 


i 


CENTER 

ANNUAL 

FLIGHT 

PLANS 

FROM 

FSSs 

AVERAGE 

DAY 

BUSY 

HOUR 

AVERAGE 

DAY 

PEAK 

DAY 

BUSY 
HOUR 
PEAK  DAY 

Chicago 

277,647 

761 

54 

1,126 

80 

Cleveland 

547,260 

1,499 

130 

2,181 

190 

New  York 

546,248 

1,497 

109 

1,991 

145 

Atlanta 

27?, 811 

750 

*4 

1,045 

89 

Washington,  D.C. 

287,821 

789 

63 

1,049 

84 

Indianapolis 

308,777 

846 

67 

1,225 

97 

Ft.  Worth 

270,707 

742 

59 

1,099 

88 

Memphis 

323,141 

885 

71 

1,292 

103 

Los  Angeles 

219,335 

601 

51 

836 

71 

Jacksonville 

260,087 

713 

80 

1,065 

119 

Kansas  City 

279,138 

765 

59 

1,218 

94 

Houston 

378,642 

1,037 

89 

1,655 

142 

Miami 

224,692 

616 

49 

911 

72 

Minneapolis 

212,137 

581 

44 

937 

70 

Boston 

318,875 

874 

71 

1,309 

106 

Oakland 

129,175 

354 

31 

460 

40 

Albuquerque 

165,394 

453 

41 

770 

70 

Denver 

64,323 

176 

17 

232 

22 

Seattle 

128,208 

351 

27 

565 

43 

Salt  Lake  City 

71,362 

196 

16 

329 

33 

5,286,770 
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In  order  to  obtain  a  measure  of  how  many  flight  plans  are 
filed  through  the  centers,  the  annual  number  of  flight  plans 
filed  through  the  FSS  were  deducted  from  the  annual  departures 
from  each  center  -  the  assumption  being  that  every  departure 
constitutes  a  flight  plan.  These  numbers  are  presented  in  Table 
B-4  again  with  a  conversion  to  average  day.  Table  B-4  also 
includes  the  number  of  annual  flights  per  center  and  the  ratio  of 
flight  plans  filed  through  each  center  to  annual  flights.  This 
factor  is  used  later  in  the  derivation  of  1985  and  1995  data. 

B.3  PROCEDURE  FOR  ESTIMATING  1985  ACTIVITY  DATA  FOR 

REPRESENTATIVE  HIGH,  MEDIUM,  AND  LOW  DENSITY  CENTERS 

B.3.1  Estimation  of  Traffic  Shares  in  1985 

The  first  step  in  developing  1985  activity  data 
representative  of  high  (Chicago),  medium  (Memphis),  and  low 
(Denver)  density  centers  was  to  obtain  the  1985  forecast  figures 
of  15.5  million  departures  and  7.4  million  overs.  (See  Table  B- 
5).  The  non-CONUS  shares,  4.5%  of  departures  and  5.6%  of  overs 
in  1975,  as  derived  in  Section  B.2.1,  were  then  deducted  to 
obtain  the  following  1985  totals,  representative  of  the  20  CONUS 
centers: 

Departures  14.7 

Overs  6 . 9 

Flights  36.3  (twice  the  departures 

plus  the  overs). 

Separate  shares  of  the  above  1985  totals  for  each  of  the 
three  subject  centers  were  obtained  by  using  the  1975  percentages 
included  in  Table  B-2  for  departures  and  overs.  These  figures 
are  listed  below. 

CENTER  DEPARTURES  OVERS  FLIGHTS 

Chicago  1,264,200  (8.6%)  303,600  (4.4%)  2,832,000 

Memphis  676,200  (4.6%)  476,100  (6.9%)  1,828,500 

Denver  367,500  (2.5%)  379,500  (5.5%)  1,114,500 

Using  the  counts  for  departures,  overs,  and  flights  developed 
above,  1985  air  activity  data  for  the  three  centers  was 
calculated  and  compiled  in  Table  B-6.  The  peak  day  and  busy 
hour-peak  day  factors  were  those  generated  from  the  1975  activity 
data.  Table  B-7  contains  busy  hour  flights  and  flight  plans  for 
average  and  peak  days.  Refer  to  Table  B-8  for  the  equations  used 
to  generate  the  data  in  both  Tables  B-6  and  B-7. 

B.4  ESTIMATES  OF  1995  ACTIVITY  DATA 

B.4.1  Derivation  of  1995  Traffic  Shares 


FLIGHT  PLAN  FILED  THROUGH  CENTERS  IN  1975 
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TABLE  B-S.  IFR  AIRCRAFT  HANDLED  FAA  AIR  ROUTE  TRAFFIC  CONTROL  CENTERS 


(In  millions) 


Total 

Aircraft  Handled  | 

Fiscal 

Aircraft 

IFR 

Air 

Air 

General 

Year 

Handled 

Departures 

Over* 

Carrier 

Taxi 

Aviation 

Military 

Historical* 

1973 

22.8 

8.9 

5.1 

12.6 

.9 

4.6 

4.7 

1974 

22.9 

9.0 

4.9 

12.4 

1.1 

5.1 

4.3 

1975 

23.6 

9.3 

5.1 

12.4 

1.3 

5.5 

44 

1976 

23.9 

9.4 

5.1 

12.4 

1.4 

6.0 

4.2 

1977 

26.0 

10.2 

5.6 

13.0 

1.6 

6.9 

4.5 

1978E 

28.1 

11.1 

5.9 

13.6 

1.9 

8.2 

4.4 

Forecast 

1979 

29.7 

11.8 

6.1 

14.1 

2.3 

8.9 

4.4 

1980 

31.1 

12.4 

6.3 

14.3 

2.7 

9.7 

4.4 

1981 

32.5 

13.0 

6.5 

14.6 

2.9 

10.6 

4.4 

1982 

34.0 

13.6 

6.8 

14.9 

3.3 

11.4 

4.4 

1983 

35.4 

14.2 

7.0 

15.2 

3.7 

12.1 

4.4 

1984 

36.9 

14.9 

7.1 

15.4 

4.1 

13.0 

4.4 

1985 

38.4 

15.5 

7.4 

15.7 

4.3 

14.0 

4.4 

1986 

39.7 

16.1 

7.5 

16.0 

4.5 

14.8 

4.4 

1987 

41.4 

16.8 

7.8 

16.5 

5.0 

15.5 

4.4 

1988 

42.8 

17.4 

8.0 

16.8 

5.4 

16.2 

4.4 

1989. 

44.2 

18.0 

8.2 

17.1 

5.6 

17.1 

4.4 

1990 

45.6 

18.6 

8.4 

17.4 

5.8 

18.0 

4.4 

E  Estimate  'Source:  FAA  Air  Trattic  Activity. 

Prior  to  1977,  me  fiscal  year  ended  June  30. 

Detail  may  not  add  to  total  due  to  independent  rounding. 

The  aircraft  handled  count  consists  of  the  number  of  IFR  departures  multiplied  by  two  plus  the  number  of  overs.  This  concept  recognizes  mat 
for  each  departure  there  is  a  landing.  An  IFR  departure  is  defined  as  an  original  IFR  flight  plan  filed  either  prior  to  departure  or  after  becoming 
airborne.  An  overflight  originates  outside  the  ARTCC  area  and  passes  through  the  area  without  landing.  The  forecast  data  assume  present 
operating  rules  and  procedures.  Air  taxi  includes  commuter. 


Source:  "FAA  Aviation  Forecasts  Fiscal  Years  1979-1990,"  Published  in 
1978  by  FAA  Office  of  Aviation  Policy. 
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TABLE  B-6  1985  AIR  TRAFFIC  ACTIVITY  DATA  FOR  CHICAGO,  MEMPHIS,  AND  DENVER 
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(Annual  Flights  Handled  1985) 


Between  1985  and  1990,  the  annual  Increase  in  departures  and 
overs  was  0.6  and  0.2  million,  respectively.  Assuming  that  these 
annual  increments  are  sustained  through  1995,  one  can  then  add 
3.0  (5  x  0.6)  million  to  the  1990  forecast  departures  of  18.6 
million  and  1.0  (5  x  0.2)  million  to  the  1990  forecast  overs  of 
8.4  million  to  obtain  21.6  and  9.4  million,  respectively,  for 
1995. 


Assuming  that  the  non-CONUS  radar  shares  of  departures  and 
overs  continues  as  in  1975  to  be  5.2%  and  in  1995  to  be  6.8%,  and 
deducting  these  shares  from  the  1995  projected  estimates,  20.5 
million  departures  and  8.8  million  overs  are  obtained  as 
indicated  below. 


B-ll 


21.6  x  0.052  -  1.1232  21.6000 

1.1232 

20.4768  million  departures 
9.4  x  0.068  »  0.6392  9.4000 

0.6392 

8.7608  million  overs 

Separate  shares  of  the  estimated  1995  forecast  departures 
and  overs  for  each  of  the  three  subject  centers  were  obtained  by 
using  each  center's  percentage  of  1975  departures  and  overs. 
These  Figures  are  included  in  Table  B-9. 


TABLE  B-9 

CENTER 

CONUS 

Chicago 

Memphis 

Denver 


CHICAGO,  MEMPHIS,  AND  DENVER  SHARES  OF  1995 
FORECAST  TRAFFIC 


FLIGHTS* 

49,714,400 

3,907,475 

2,488,355 

1,505,685 


DEPARTURES 
20,476,800 
1,761,000  (8.6%) 
941,930  (4.6%) 
511,920  (2.5%) 


OVERS 

8,760,800 

385,475 

604,495 

481,845 


(4.4%) 

(6.9%) 

(5.5%) 


*Twice  the  departures  plus  the  overs. 


B.4.2  Peak  Day  Departure  Estimates 

In  Table  B-10,  the  figures  from  Table  B-9  were  converted  to 
average  daily  figures  as  part  of  the  process  of  estimating  busy 
hour  and  peak  day  figures  using  the  peaking  factors  developed 
from  the  1975  data.  The  procedure  used  to  derive  "Total 
Departures-Peak  Day  1995"  and  "Busy  Hour  Departures  Peak  Day 
1995"  is  shown  below. 


Chicago  1995 

Since  the  estimated  forecast  of  Total  Departures-Average  Day 
1995  is  4,825,  then 

Total  Departures-Peak  Day  4  4825  *  1.479 
Total  Departures-Peak  Day  1995  ■  7,136. 

Since  Total  Departures-Peak  Day  1995  is  7,136,  then. 

Busy  Hour  Departures-Peak  Day  1995  4  7136  *  0.071 
Busy  Hour  Departures-Peak  Day  1995  *  507 

Memphis  1995 

Since  the  estimated  forecast  of  Total  Departures-Average  Day 
1995  is  2,581,  then 
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Total  Departures-Peak  Day  1995  2,581  *  1.455 

Total  Departures-Peak  Day  1995  *  3,755 
Since  Total  Departures-Peak  Day  1995  is  3,768,  then 

Busy  Hour  Departures-Peak  Day  1995  3755  *  0.080 

Busy  Hour  Departures-Peak  Day  1995  =  300 

Denver  1995 

Since  the  estimated  forecast  of  Total  Departures-Average  Day 
1995  is  1,403,  then 

Total  Departures-Peak  Day  1995  *  1403  *  1.32 

Total  Departures-Peak  Day  1995  *  1,852 

Since  Total  Departures-Peak  Day  1995  is  1,852,  then 

Busy  Hour  Departures-Peak  Day  1995  v  1852  *  0.095 

Busy  Hour  Departures-Peak  Day  1995  =  176. 

B.4.3  FI iqht  Plans  Handled 

In  order  to  calculate  the  number  of  flight  plans  filed 
through  the  three  subject  centers  and  the  FSSs  associated  with 
each,  the  following  equations  were  used: 

FPs  filed  through  Centers  1995  =  (Annual  Flights  1995)  * 

(FPs  filed  through  Centers  1975  f  Annual  Flights  1975) 


FPs  filed  through  FSSs  1995  =  (Annual  Departures  1995)  - 
(Annual  FPs  filed  through  Centers  1995) 


In  Table  B-4  the  percentage  of  annual  flights  representative 
of  the  flight  plans  fried  through  each  center  in  1975  was 
calculated  for  each  center.  The  percentages  for  Chicago, 

Memphis,  and  Denver  (27.8,  0.071,  and  0.22,  respectively)  were 
then  taken  off  the  annual  flights  for  each  center  in  1995  and 
entered  in  Table  B-ll.  By  subtracting  the  flight  plans  filed 
through  each  center  in  1995  from  the  annual  departures  from  each 
center,  the  number  of  flight  plans  filed  through  each  center's 
associated  set  of  flight  service  stations  was  obtained. 

Data  in  Table  B-ll  was  then  used  to  develop  busy  hour  counts 
and  peak  instantaneous  counts  presented  in  Table  B-12. 


TABLE  B-12  1995  BUSY  HOUR  AND  PEAK  INSTANTANEOUS  COUNTS  FOR  CHICAGO 

MEMPHIS,  AND  DENVER 
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APPENDIX  C 


SURVEY  OF  NAS  EN  ROUTE  SYSTEM  PERFORMANCE 
C.l  INTRODUCTION 

Existing  studies  of  the  NAS  En  Route  System  were  reviewed  to 
correlate  the  considerations  of  the  replacement  system  with 
respect  to  processing  load  estimates  and  determining  feasible 
transition  paths.  The  foremost  objective  was  the  verification  of 
the  replacement  system  functional  load  estimates  with  measurement 
data  of  the  current  system. 

The  replacement  system  is  expected  to  be  implemented  by  the 
late  1980's.  Projections  of  how  the  current  system  would  evolve 
during  this  time  frame  were  made.  This  allows  consideration  of 
the  feasibility  of  possible  transition  paths  to  the  replacement 
system.  These  projections  entailed  developing  an  understanding 
of  the  current  system's  performance  and  limitations.  Air  traffic 
loads  on  the  computer  systems  were  estimated.  Various 
alternatives  for  extending  the  capacity  to  meet  these  estimated 
loads  were  reviewed. 

This  work  represents  an  overview  approach  for  developing  a 
global  comprehension  and  identifying  areas  that  warrant  further 
investigation.  The  readily  available  literature  was  surveyed, 
liberal  reasonable  assumptions  were  employed,  and  varying  levels 
of  detail  were  considered.  The  reader  is  assumed  to  have  general 
familiarity  with  ATC,  the  NAS  En  Route  System,  computer 
performance,  and  computer  architecture. 

C . 2  VERIFICATION  OF  FUNCTION  PROCESSING  LOAD  ESTIMATES 

The  methodology  of  the  functional  processing  load  estimates 
in  Sections  2. 2. 2. 2  and  2. 2. 2. 3  was  verified  by  examining  the 
possible  correlations  with  measurement  data  of  the  current 
system.  Limiting  the  estimates  to  an  order  of  magnitude  accuracy 
permitted  the  use  of  readily  available  measurement  data  on 
release  NAS  En  Route  3d2.1  System.  These  data  were  the  same  as 
those  used  for  the  basis  of  Kelley's  study  "Distributed 
Processing  Techniques  for  En  Route  Air  Traffic  Control."*  The 
use  of  common  data  may  facilitate  future  comparisons. 

The  original  measurement  data  is  from  the  System  Performance 
Analysis  Report-48  (SPAR)  and  SPAR-55  studies  of  release  3d2.1. 
The  26  program  elements  with  highest  processor  utilization  were 
considered.  These  account  for  over  90%  of  the  total  processor 
utilization. 


*Kelley,  James  P.  "Distributed  Processing  Techniques  for  En  Route 
Air  Traffic  Control,"  The  MITRE  Corporation,  METREK  Division,  Me 
Lean  VA. ,  MITRE  Technical  Report  7589,  July  1977. 
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The  correlation  between  the  program  element  of  3d2.1  and  the 
functional  description  of  the  replacement  system  is  complex  and 
incomplete.  However,  five  disjoint  groupings  with  reasonable 
correlations  exist  and  are  illustrated  in  Figures  C-l  and  C-2. 
These  five  groupings  allowed  the  verification  of  the  load 
estimation  method.  Of  the  functions  not  correlated  in  these 
groupings,  conflict  alert  is  among  the  most  notable. 

The  relationship  between  program  elements  and  the  functions 
are  depicted  by  the  straight  lines  between  the  two  listings.  A 
straight  line  between  a  program  element  of  3d2.1  and  a  function 
of  the  replacement  system  indicates  significant  commonality  of 
the  work  performed.  As  graphically  portrayed  in  Figures  C-l  and 
C-2,  correlation  among  groups  1,  2,  and  3  is  much  simpler  than 
among  groups  4  and  5. 

An  approximation  of  each  function's  load  processing  estimate 
for  110  tracks,  40  displays  and  5  radars  is  calculated.  Each 
approximation  is  reduced  to  a  function  of  one  processing  rate 
constant,  K  small/  using  the  rule  of  thumb,  Kiar„e  =  10  K^^ium  * 
100  Ksniaj j,  in  section  2. 2. 2. 2.  Thus  the  processing  estimate  for 
the  functions  in  Table  2.2-5  are  reduced  to  the  quantities  in 
Table  C-l.  The  first  column  gives  the  approximation  used  for 
load  estimation  verification.  The  sums  of  reduced  function  load 
estimates  are  given  in  column  3  of  Table  C-2  for  each  group. 

The  measured  processing  load  for  each  program  element  is 
totalled  for  all  program  elements  in  each  group.  These  sums  in 
terms  of  sec/sec  of  a  9020A®  cpu  are  given  in  column  1  of  Table 
C-2. 


The  relationship  between  the  processing  proportionality 
K small  an<*  the  9020A  CPU  is  not  known.  Assuming  the  load 
estimates  are  exact  for  each  group,  a  value  of  Ksmall  for  each 
group  is  determined  and  given  in  column  4  of  Table  C-2.  In 
column  5,  the  Ksmall  values  are  normalized  to  the  group  3  value. 


Thus,  column  5  has  the  range  of  variation  of  the  Ksmall 
values  found  by  assuming  equalities  between  the  measured  and 
estimated  group  loads.  The  range  of  variation  is  within  the 
order  of  magnitude  accuracy  of  the  estimation  method.  The 
agreement  is  better  in  the  first  three  groups  which  have  simpler 
relationships.  The  order  of  magnitude  accuracy  of  the  processing 
load  estimates  for  the  functions  in  the  five  groups  have  been 
verified  indirectly  by  the  observed  variation  in  column  5  of  the 
normalized  Ksnan  values. 


C . 3  DESCRIPTION  OF  THE  CURRENT  NAS  EN  ROUTE  SYSTEMS 


The  NAS  En  Route  Systems  hardware  in  the  ARTCCs  has  three 
different  configurations  Each  has  two  major  components,  a 
computational  subsystem,  k.ie  CCC,  and  a  display  subsystem.  There 
are  twenty  operational  ARTCCs  covering  the  U.S.  airspace.  Ten  of 
these  have  the  complex  composed  of  the  IBM  9020A  CCC 
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TABLE  C-l  PROCESSING  ESTIMATES  FOR  EN  ROUTE  FUNCTIONS  FOR: 

"irj.  , 


Npp=  2Nt,  Nd=  40,  Nr=  5, 


P  in 

Ks  for 

T  = 

FUNCTION 

100 

200 

400 

Radar  Data  Preliminary  Processing 

oNt.Nr 

SxlO3 

lxlO4 

2xl04 

Tracking  (FLAT  and  Free) 

aNT 

2xl03 

4xl03 

8xl03 

Track  Acquisition 

aNT 

2X101 

4X101 

8xlOX 

Target/Track  Correlation 

aNTlnNT.Np 

2 . 5xl03 

3xl03 

3 . 3xl03 

Display  Data  DBM 

aC 

103 

103 

103 

Display  Generation 

aN,p .  Np 

2xl03 

4xl03 

8xl03 

Display  Control 

aND 

101 

101 

101 

Route  Conversion 

aC 

102 

102 

102 

Track  DBM 

aC 

103 

103 

103 

Flight  DBM 

ctC 

103 

103 

103 

Association  Checking 

aRp 

5X101 

lxlO2 

2xl02 

Message  Processing 

aC 

103 

103 

103 

Flight  Plan  Position  Determination 

aNy 

5X101 

102 

2xl02 

Fix  Time  Calculation 

aC 

102 

102 

102 

Posting  Determination 

aC 

SxlO1 

5X101 

SxlO1 

Flight  Plan  Activation 

aNT 

5X10'1 

1 

2 

Bulk  Store  Processing 

aC 

2xl03 

2x10" 3 

2xl0'3 

Beacon  Code  Allocation 

ctC 

1 

1 

1 

0.  and  E.  DBM 

aC 

103 

103 

103 

10' 


Conflict  Alert 


aNj. InNj 


76 


88 


TABLE  C-2  LOAD  ESTIMATES  AND  THEIR  RATIOS 


* 

( 


Program 

Element 

Groups 

Sum  of  Program 
Element  Load 
in  sec/sec-of 
IBM  9020A©cpu 

Sura  of  Function 
Load  Estimates 

Ksmall 

Calculated 

Values 

^small 

Normalized 

Values 

Ksmall 
(to  Group 

3  value) 

1 

0.40 

5500 

7 , 3x10*5 

2.6 

2 

0.18 

2500 

7 . 2xl05 

2.6 

3 

0.056 

2000 

2 . 8xlQ5 

1.0 

4 

0.71 

3200 

22 .xlO*  5 

7.9 

5 

0.45 

2000 

23.xl0~5 

8.2 

_ ; 

computational  subsystem  and  the  Raytheon  730®  Channel  Display 
Controller  (CDC)  display  system.  Five  consist  of  the  IBM  9020D® 
(DCC)  computational  subsystem  and  the  IBM  9020E®  DCC.  These 
systems  complexes  are  depicted  in  Figure  C-3. 

The  display  subsystems  appear  adequate  for  the  future.  The 
Raytheon  730  CDC  can  drive  up  to  60  display  positions,  while  the 
triplex  IBM  9020E  DCC  can  drive  up  to  90.  These  limitations  are 
within  the  projected  load  requirements  through  the  late  1980's. 
The  available  literature  gives  no  indication  of  serious 
limitations  in  either  the  CDC  or  DCC. 

The  focus  of  this  survey  is,  therefore,  on  the  computing 
subsystem,  the  CCC.  Both  the  IBM  9020A®  and  the  9020D  have 
limitations  which  may  become  operational  performance  issues  by 
the  late  1980’s.  The  computing  subsystem  encompasses  the  major 
areas  of  interest  for  the  replacement  system  design,  as  most  of 
the  replacement  baseline  functions  are  performed  in  the  current 
computing  subsystem. 

The  IBM  9020A  and  9020D  CCCs  have  a  distributed  asynchronous 
bus  structure  very  similar  to  the  General  Electric  (GE)  MULTICS®, 
Burroughs  5000®,  and  Digital  Equipment  Corporation  (DEC)  PDP-10® 
architectures.  The  three  main  components  are  the  computer 
elements  (CE),  the  input-output  control  elements  (IOCE),  and  the 
storage  elements  (SE).  The  component  technology  is  the  IBM  solid 
logic  technology®  ( SLT ) .  The  engineering  is  standard  IBM  360/50® 
and  IBM  360/65®  except  for  the  distributed  bus  and  its 
interfaces. 

The  9020A  and  9020D  differ  in  the  CEs  and  SEs.  The  CEs  and 
SEs  of  the  9020A  are  modified  versions  of  IBM  360/50  design.  The 
9020D  has  IBM  360/65  engineering  in  its  CE  and  SE  .  The  IOCEs 
employ  IBM  360/50  engineering  and  are  identical  for  both  the 
9020A  and  the  9020D  CCCs. 

The  major  peripherals  of  interest  are  the  disks,  IBM  2314®, 
the  tapes,  IBM  2401®,  and  the  perioheral  adapter  modules  (PAM), 
which  are  heavily  customized  IBM  2701®.  The  PAMs  control  all 
communications  for  the  computing  system  except  for  the  link  to 
the  CDC  or  DCC.  A  comparison  cf  the  9020A  and  9020D 
characteristics  is  given  m  Table  C-3. 

As  indicated  in  Table  C-3  and  Figure  C-4  the  9020A  is  a  four 
processor  CE  system.  Normally  one  of  each  major  element  is  kept 
on  standby,  redundant,  in  case  of  an  element  failure.  The  9020D 
diagrammed  in  Figure  C-5  is  a  three  processor  system  that 
normally  operates  with  two  processors  on-line. 

The  IOCEs  each  have  two  selector  channels  (S),  one 
multiplexer  channel  (MX)  and  1 3 1 k  bytes  of  local  memory.  One 
selector  channel  for  each  IOCE  normally  communicates  with  the  CDC 
or  DCC.  The  second  selector  channel  is  used  for  disk  and  tape 
activity.  The  multiplexer  channel  handles  the  PAM.  Redundant 
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TABLE  C- 3  IBM  9020A  ^  AND  90200  ^  CHARACTERISTICS 


Characteristic 

9020A 

9020D 

CE  cycle  time 

0.5  ysec 

0.2  psec 

SE  cycle  time 

2.5  usec/4 

bytes  0.8  usec/8  bytes 

SE  capacity/unit 

0.25  megabyte  0.5  megabyte 

Number  or  Capacity 

On-line 

9  02  0A  9020D 

Total  On-line 

Total 

CE 

3  • 

4  2 

3 

SE 

9 

11  5 

6 

Total  memory 

2  1/4  mb 

2  3/4  mb  2  1/2  mb 

3  mb 

PAM 

2 

3  2 

3 

Tape  Controller 

2 

3  2 

3 

Disk  Controller 

2 

3  2 

3 

Disk  Drive 

2 

6  2 

6 
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paths  are  supplied  by  use  of  dual  channel  controllers  for  the 
disks,  tapes,  and  multiple  connections. 


The  centers  with  the  9020A®  CCC  routinely  keep  two  SEs  off¬ 
line.  This  allows  use  of  the  off-line  redundant  elements  for 
performing  required  data  processing  (DP)  operations.  The  minimum 
useful  core  needed  is  1/2  megabyte  for  the  DP  functions.  Thus, 
two  9020A  SEs  are  used,  while  one  9020D®  SE  is  used  for  DP 
functions.  The  9020A  CCC  typically  has  2-1/4  megabytes  on-line 
storage;  and  the  9020D  CCC  has  2-1/2.  The  memory  for  both  the 
9020A  and  9020D  is  not  interleaved.  This  facilitates 
reconfiguration  if  an  SE  should  fail.  The  usual  on-line 
configurations  are  depicted  to  the  left  side  of  the  dashed  lines 
in  Figures  C-l  through  C-3. 

C . 4  PROJECTED  PEAK  AIR  TRAFFIC  LOADS  IN  THE  LATE  1980 's 

Estimates  were  made  of  peak  track  counts  for  1977.  As 
stated  in  the  Federal  Computer  Performance  Evaluation  and 
Simulation  Center  (FEDSIM)  study,*  the  track  count  is  the  best 
single  load  metric  and  is  an  adequate  load  parameter  for  this 
survey.  The  heavy  peak  track ^counts  observed  in  the  1977  Logicon 
Study  of  the  Fort  Worth  ARTCC**  were  used  as  the  basis  for 
estimating  other  ARTCC  peak  track  counts.  Estimates  of  1975  IFR 
flights  were  assumed  to  be  proportional  to  1977  peak  track 
counts.  The  estimates  are  given  in  Table  C-4. 

Table  C-4  also  gives  the  ARTCC  configurations  and  the  number 
of  sectors.  With  the  exception  of  Houston,  the  larger  peak  track 
counts  are  9020D  configurations.  Peak  track  count  is  the  best 
single  metric,  but  other  factors  should  be  considered  when  better 
than  ±10%  accuracy  is  desired. 

The  air  traffic  growth  estimates  range  between  2%  and  6%  per 
year  with  4.4%  as  the  best  estimate.  Figure  C-6  shows  the 
estimated  peak  track  growth  of  the  9020A  and  9020D  maximum  peak 
counts.  The  9020A  maximum  peak  count  in  1977  was  assumed  to  be 
200,  and  the  9020D  maximum  in  1977  is  300.  The  growth  curve  of 
the  9020A  maximum  peak  count  also  shows  the  range  limits  of  2% 
and  6%  per  year  growth. 

Thus  in  1985  the  estimated  maximum  peak  track  count  for  a 
9020A  center  is  between  233  and  318,  with  the  best  estimate  at 
280.  The  maximum  peak  count  for  the  9020D  ARTCC  in  1985  is  425, 
assuming  a  4.4%  per  year  growth  rate. 


* "NAS  Capacity  Study,"  FEDSIM,  Washington  D.C.,  Contract  Number 
AY-4 09-0 08 -TSC,  November  1975. 

**  Kandler,  W.D.,  et.  al.,  "Response  Time  Analysis  Study  Fort 
Worth  ARTCC  Measurements"  Logicon,  Inc.  Atlantic  City  NJ, 
Contract  Number:  DOD-RATQWA-3881 ,  Logican  Report  Number:  R4940- 
107,  August  1977  (NAS  Doc.  78-0211). 
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TABLE  C-4  ESTIMATED  TRAFFIC  AND  HARDWARE  ARTC  CONFIGURATIONS 


CENTER 

ESTIMATED 

PEAK 

TRACK 

COUNT 

(1977) 

ESTIMATED 

IFR  FLIGHTS  (1975) 

CONFIGURATION 

(COMPUTING)/ 

(DISPLAY) 

NUMBER 

OF 

SECTORS 

PEAK  DAY 
BUSY  HOUR 

AVG.  DAY 
BUSY  HOUR 

ANNUAL 

TOTAL 

Cleveland 

301 

527 

395 

1,655,816 

[BM902  01^/9020^ 

47 

Chicago 

275 

481 

336 

1,724,441 

9020D/9020E 

43 

Jacksonville 

246 

435 

254 

1,092,133 

9020D/RAY73<^ 

37 

Atlanta 

243 

426 

322 

1,383,014 

9020D/730 

41 

Fort  Worth 

229 

401 

286 

1,305,953 

9020D/IBM9020E 

39 

New  York  City 

220 

385 

307 

1,533,014 

9020D/9020E 

39 

Washington  DC 

218 

382 

302 

1,378,370 

9020D/9020E 

36 

Houston 

215 

376 

247 

1,046,545 

9020A57RAY730 

41 

Indianapolis 

213 

372 

285 

1,316.443 

9020D/730 

34 

Los  Angeles 

198 

346 

254 

1,092,133 

9020D/730 

37 

Kansas  City 

190 

332 

230 

1,079,663 

9020D/730 

36 

Memphis 

190 

332 

250 

1,138,534 

9020A/730 

36 

Albuquerque 

189 

327 

218 

875,362 

9020A/730 

34 

Miami 

177 

310 

222 

1,024,853 

9020A/730 

28 

Minneapolis 

174 

305 

208 

1,011,297 

9020A/730 

34 

Boston 

163 

286 

204 

917,781 

9020A/730 

32 

Oakland 

154 

269 

212 

890,893 

9020A/730 

39 

Seattle 

125 

219 

140 

670,501 

9020A/730 

22 

Denver 

125 

218 

181 

696,778 

9020A/730 

34 

Salt  Lake  Citj 

98 

172 

123 

448,918 

1 

9020A/730 

21 
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FIGURE  C-6  ESTIMATED  PEAK  TRACK  COUNTS 


In  addition  to  anticipated  traffic  growth,  planned 
enhancements  to  be  implemented  by  the  late  1980's  will  increase 
the  resource  requirements  of  the  CCC.  Table  C-5  gives  the 
estimated  memory  and  Central  Processing  Unit  (CPU)  requirements 
for  each  enhancement.  If  all  the  enhancements  listed  are 
implemented,  an  additional  730  kbytes  of  memory  and  0.39  sec  per 
sec  of  a  9020A®  CPU  equivalent  will  be  required.  These  estimates 
are  for  a  track  count  of  225  and  the  1978  base,  version  3d2.8. 

The  additional  CPU  requirement  of  0.4  sec  per  sec  of  a  9020A 
CPU  is  roughly  equivalent  to  30  tracks  at  a  total  track  count  of 
200  or  about  a  15%  CPU  increase.  Thus  all  these  enhancements 
would  add  an  equivalent  15%  load  to  the  traffic  growth  curves  in 
Figure  C-6.  With  all  enhancements,  the  equivalent  maximum  peak 
track  counts  in  1985  for  4.4%  per  year  growth  are  488  for  the 
busiest  9020D®  center  and  322  for  the  busiest  9020A  center.  This 
is  a  possible  60%  increase  in  the  total  CPU  requirement.  The 
memory  storage  requirements  for  all  enhancements  is  equivalent  to 
a  25%  increase. 

The  enhancement  estimates  and  the  implementation  schedule  is 
subject  to  question  in  detail,  but,  nevertheless,  give  rough 
estimates  of  the  requirements  increase  in  addition  to  the  traffic 
growth.  For  this  survey,  an  annual  traffic  increase  of  4.4%  per 
year  with  an  additional  15%  CPU  and  25%  memory  requirement  by  the 
late  1980 's  was  assumed.  Input/Output  (I/O)  requirements  for  the 
enhancements  were  not  estimated. 

These  assumptions  give  equivalent  peak  track  counts  of 
approximately  488  for  the  busiest  9020D  center  and  325  for  the 
busiest  9020A  center  in  1985.  This  is  a  60%  increase  over  1977. 
In  1990  the  nominal  growths  with  enhancements  give  maximum  peak 
counts  of  402  tracks  for  the  busiest  9020A  center  and  607  tracks 
for  the  busiest  9020D  center. 

Estimated  peak  counts,  without  enhancements  and  nominal 
traffic  growth  for  the  busiest  9020A  centers,  is  280  tracks  in 
1985  and  350  tracks  in  1990.  For  the  busiest  9020D  centers,  the 
corresponding  counts  are  422  tracks  in  1985  and  527  tracks  in 
1990. 

C . 5  LIMITATIONS  OF  CURRENT  NAS  EN  ROUTE  SYSTEM 

The  9020A  and  9020D  CCC  were  reviewed  with  respect  to  their 
current  air  traffic  capacity  versus  the  estimated  air  traffic 
load  in  the  late  1980's.  The  data  indicates  that  the  9020A  CCC 
has  serious  limitations  with  respect  to  maximum  peak  track 
counts.  By  1985  the  maximum  peak  track  count  for  the  busiest 
9020A  center  may  exceed  the  capacity  of  the  current  9020A 
configuration.  In  the  late  1980's,  this  capacity  will  most 
likely  not  be  adequate  for  peak  loads. 

The  CCC  is  a  real  time  system  in  many  of  its  performance 
requirements  and  must  meet  these  real  time  requirements  under 
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TABLE  C-5  ENHANCEMENT  ESTIMATES  FOR  CPU  AND  MEMORY 
(by  MITRE,  1978  Base,  225  Tracks) 


Storage 

CPU 

sec/seccs 
IBM  9020AViyCE 

Major  Enhancements 

kilobytes 

Conflict  Predict 

220 

0.15 

En  Route  MSAW 

120 

0.10 

Conflict  Alert 

80 

0.07 

DABS  Interface 

50 

0.04 

Conflict  Resolution 

30 

0.01 

Metering 

_  4_0 

0.01 

Subtotal 

540 

0.38 

Secondary  Enhancement 

ETABS 

40 

0.15  +  0 

FSS  Auto 

0 

0 

Weather 

0 

o 

NAD  IN 

+80  +  -20 

0 

DARC 

12 

*3- 

o 

> 

o 

TIPS 

30 

0 

ATARS 

4 

0 

ARTS  III  $  II 

0 

0 

ATCSCC 

0 

0 

CMA 

120 

0.005 

Oceanic  Auto 

4 

0 

Subtotal 

190 

0.009 

TOTAL 

730 

0.39 

SOURCE:  Dodge,  P.O.,  "9020  Sizing  Estimates  for  SRDS  Planned 
Automation  Enhancements,"  MITRE  Corporation/METREK 
Division,  McLean,  VA,  Briefing  Viewgraphs,  January 
25,  1979. 


C-16 


1 


peak  loading  conditions.  Originally,  the  CCC  program  elements 
and  active  data  were  to  be  resident  in  primary  memory,  and  no 
disks  were  to  be  used.  The  computing  capacity  of  the  9020A®  was 
to  be  more  than  adequate.  The  latter  use  of  disks  for  swapping 
program  elements  was  employed  without  increasing  the  original  I/O 
capacity.  Where  the  9020A  processing  capacity  was  inadequate,  an 
enhanced  version,  designated  the  9020D®,  was  employed. 

The  upgrade  to  the  9020D,  with  computer  elements  more  than 
3-1/2  times  the  processing  capacity  of  the  9020A  CE,  gives  a 
duplex  9020D  2.4  times  the  CPU  capacity  of  a  triplex  9020A.  The 
I/O  composition  of  the  9020A  and  9020D  configurations  are 
identical.  The  operational  capacity  of  the  primary  memory  of  the 
9020A  and  9020D  are  very  similar  as  seen  in  Table  C-3.  The  most 
significant  difference  between  the  9020A  and  the  9020D  is  CPU 
capacity. 

Rough  estimates  give  a  routine  peak  count  capacity  of  the 
9020A  to  be  about  175  tracks  and  the  9020D  about  235  tracks.  In 
actual  operation,  the  capacity  is  extended  by  reducing  or 
eliminating  data  recording,  bringing  redundant  elements  on-line, 
and  reducing  capabilities. 

Crude  estimates  of  the  effect  of  employing  these  non-routine 
means  of  increasing  capacity  give  a  peak  track  count  capacity  of 
300  tracks  for  the  9020A  CCC  and  500  tracks  for  the  9020D  CCC. 
These  estimates  should  be  explored  further.  They  indicate  a 
possible  shortfall  of  capacity  during  peak  traffic  loads  for  the 
busiest  9020A  centers  by  1985. 

The  means  of  reducing  or  eliminating  data  recording  does  not 
seriously  affect  operational  capabilities.  Failure  of  an  SE  or 
CE  during  a  mode  of  operations,  where  all  elements  of  the  type  to 
fail  were  on-line  in  order  to  meet  peak  load  demands,  is  a 
situation  whose  remedies  should  be  carefully  explored. 

An  abundance  of  very  good  measurement  studies  has  been  made 
of  the  NAS  En  Route  State  System.  Each  new  version  is  tested  at 
National  Aviation  Facilities  Experimental  Center  ( NAFEC )  and  many 
field  studies  have  been  performed.  These  studies  give  a  good 
overall  performance  understanding  of  the  NAS  En  Route  System. 

For  a  more  detailed  (accuracy  better  than  +10%)  understanding, 
more  work  is  needed  to  better  correlate  the  NAFEC  tests  with 
field  measurements.  The  additional  studies  are  in  progress,  or 
in  planning,  and,  when  finished,  an  accurate,  comprehensive 
performance  assessment  of  the  En  Route  System  can  be  made. 

The  needed  measurement  work  is  ably  covered  in  the  FEDSIM 
and  Logicon  studies.*  This  work  would  also  allow  the  limitations 


*Kandler,  W.D.,  "NAS  En  Route  Response  Time  Analysis  Study, 
Composite  Analysis  of  Indianapolis,  Memphis,  Forth  Worth,  and 

(Continued) 
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of  the  current  9020A®  and  9020D®  systems  to  be  determined  within 
the  accuracy  needed  for  detailed  planning.  The  limitations 
estimated  by  this  survey  are  rough  (greater  than  ±10%)  but  give 
an  indication  of  where  further  accuracy  should  be  pursued. 

The  major  items  in  the  NAFEC  test  that  reduce  accuracy  are: 
the  limited  number  of  different  traffic  loads  (two)  for  each 
configuration,  conflict  alert  being  off,  very  little  change  of 
the  data  recording  variable,  and  no  variation  in  the  amount  of 
memory  used.  The  field  measurements  are  mainly  of  hardware 
resource  utilization  and  do  not  readily  relate  to  the  detailed 
NAFEC  software  module  utilization.  Since  the  field  measurements 
are  made  during  actual  operation,  many  changes  in  the  data 
recording  variable  occur. 

Estimates  were  made  of  the  peak  track  counts  where  the 
response  times  of  the  NAS  performance  criteria  would  begin  to 
exceed  the  established  goals  noticeably.  The  range  of  the  load 
from  the  first  notice  of  exceeding  response  time  until  the 
response  time  has  increased  to  an  unacceptable  limit  is  typically 
1 0-20% .  The  accuracy  of  these  estimates,  given  in  Table  C-6,  is 
probably  not  better  than  20%. 

Comparison  of  these  peak  load  limits  to  the  peak  load 
estimate  of  Section  C.4  indicates  that  the  busiest  9020A  center 
may  have  performance  difficulties  under  peak  loads  during  the 
middle  1980 's.  The  busiest  9020D  centers  would  not  have  peak 
load  problems  until  the  late  1980's,  assuming  nominal  traffic 
growth  only.  Additional  NAS  enhancements  could  advance  these 
time  frames. 

A  simple  view  of  where  resource  limitations  occur  for  peak 
traffic  loads  in  the  9020®  system  is  given  in  Table  C-7.  The 
overall  limits  are  complex  functions  of  all  these  resources.  A 
classic  case  is  the  trade-off  between  memory  capacity  and 
processing  capacity  by  different  computational  algorithms.  Some 
of  the  many  interrelated  factors  are  given  in  Table  C-8. 

As  seen  in  Table  C-7,  the  9020A  system  has  limitations  in 
all  the  primary  resources,  if  the  full  data  recording  levels  are 
occurring.  If  recording  was  completely  eliminated,  more  than  10% 
of  processing  capacity  is  recovered,  and  about  50%  of  the  I/O 
bandwidth  is  recovered.  At  about  a  200  track  load,  a  triplex  2- 
1/2  megabyte  9020A  uses  about  50%  of  the  I/O  bandwidth  for 
program  element  swapping. 

If  a  9020A  system  had  the  memory  capacity  to  keep  all 
program  elements  resident  in  primary  memory,  and  data  recording 
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TABLE  C-6  ESTIMATED  PEAK  TRACK  COUNT  LIMITS 


IBM  9020A  ® 

Full  Data 

Reduced  Data 

Reduced  Data 

3CE,  9SE 

3CE ,  10SE 

4CE,  USE 

175 

250 

300 

IBM  9020D® 

Full  Data 

Reduced  Data 

Reduced  Data 

2CE ,  5SE 

2CE,  5SE 

3CE,  6SE 

235 

450 

550 

L9 


TABLE  0  7  PRIMARY  RESOURCE  LIMITATIONS 


(Normal  Operation  at.  Current  Traffic  Peaks) 

Resource 

IBM  9020A® 

IBM  9020D® 

I/O  Bandwidth 

Yes 

Yes 

I/O  Device  Speed 

Yes 

Yes 

Memory  Capacity 

Yes 

Yes 

Memory  Bandwidth 

Yes 

No 

Processing  Capacity 

Yes 

No 

was  eliminated,  the  system  would  still  be  limited  by  processing 
capacity  and  memory  bandwidth.  The  processing  capacity  of  the 
current  triplex  9020A®  system  is  about  200  tracks.  The  two  on¬ 
line  IOCEs  are  utilized,  approximately  20%,  for  radar  processing. 
A  potential  40%  increase  in  capacity  by  IOCE  offloading  is 
limited  by  the  memory  bandwidth  of  the  9020A  SEs. 

The  storage  interference  of  the  9020A  with  a  200  track  load 
is  estimated  to  be  10-20%  of  its  utilized  processing  capacity. 
Typically,  at  this  level  of  storage  interference,  increased 
processor  utilization  incurs  a  marked  increase  in  storage 
interference.  This  effect  can  go  beyond  the  point  of  diminishing 
returns.  The  effect  of  increased  processor  utilization  in 
storage  interference  in  the  current  9020A  system  is  not 
accurately  known. 

Simulation  of  the  9020A  system  to  measure  the 
interrelationship  of  processor  utilization  and  storage 
interference  is  feasible  and  would  be  simpler  and  cheaper  than 
actual  measurements.  This  would  allow  determination  of  the 
actual  potential  of  IOCE  off-loading. 

Depending  on  the  local  adaption  data  and  expected  load,  the 
NAS  En  Route  software  requires  between  3  and  3.5  megabytes  of 
primary  memory.  This  would  allow  all  program  elements  to  be 
resident  in  primary  memory  and  eliminate  swapping  of  program 
elements.  The  9020A  and  9020D®  centers  can  have  2.5  megabytes 
on-line  with  one  redundant  storage  element  available. 

The  minimum  buffer  size  is  slightly  less  than  0.5  megabytes. 
Thus  the  maximum  swap  ratio  is  slightly  less  than  3.  An  old  rule 
of  thumb  for  time  sharing  systems  with  9020®  I/O  technology  was 
an  upper  bound  ratio  of  3  for  acceptable  time  sharing  response. 
The  real-time  response  required  of  the  9020  system  requires 
larger  than  minimum  buffer  in  order  to  reduce  the  swap  ratio. 
Increasing  the  buffer  size  increases  the  swapping  activity.  Thus 
delicate  tuning  is  required  due  to  the  I/O  limitations  of  the 
9020  system.  Under  these  circumstances  the  memory  capacity  of 
the  9020A  and  9020D  is  considered  significantly  limited  at  peak 
traffic  loads. 

The  load  limit  estimates  in  Table  C-6  are  rough,  and  many 
complex  factors  must  be  considered.  The  data  does  indicate  that 
the  9020A  system  limitations  are  significant  with  respect  to  peak 
traffic  loads  anticipated  in  the  late  1980's.  More  accurate  and 
detailed  study  is  needed  to  explore  this  potential  problem. 

C . 6  ALTERNATIVES  FOR  INCREASING  9020  CAPACITY 

The  alternatives  for  enhancing  the  9020  system's  performance 
cover  I/O,  processing  and  memory  capacities.  The  Logicon  Study 
(March  1978)  extensively  covered  I/O  channel  utilization.  Table 
C-9  lists  the  enhancements  suggested  in  the  Logicon  work.  The 
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TABLE  C-9  RANKING  OF  CHANNEL  UTILIZATION  IMPROVEMENTS 


RECOMMEN¬ 

DATION 


SAR  Improve¬ 
ments 

New  Disk 
I/O 

Method 

Disk  Remap 

Smoothed 

Disk 

and  Tape 
I/O 

Third 
Selector 
Channel 
and  Added 
Disks 

Partial 

Cross- 

Barred 

Channels 

1600  BPI 

Tape 

Drives 

Third 

Selector 

Channel 

Disk  Shuttle 
Access  Method 

ITEL 

Disks 

Small 

SAR 

Records 


LABOR 

HOURS 

(Months) 


HARDWARE 

COST 

($1000) 


TOTAL 

COST 

($1000) 


TRACK 

CAPACITY 

INCREMENT 


200+ 


FIGURE 

OF 

MERIT 


0.70 


0.40 


0.30 

0.20 


0.12 


0.10 


0.07 


0.05 


0.05 


0.01 


-5.00 


SOURCE:  Kandler,  W.D.,  "NAS  En  Route  Response  Time  Analysis  Study, 
Analysis  of  Channel  Utilization  Improvement  Methods, 

Final  Report,  Vol.  II,  "Logican  Inc.,  Rosslyn  VA,  Contract 
Number  DOT- FAT-QWA- 3881 ,  Logican  Report  Number:  R4940-110, 
March  1978,  NAS  DOC.78-0207. 
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track  increments  are  with  respect  to  full  data  recording  and 
swapping  of  a  200  track  load. 

Processing  capacity  may  be  increased  by  further  utilization 
of  the  IOCEs.  Current  work  is  addressing  this.  However,  as 
discussed  in  Section  C-4,  the  storage  interference  in  the  9020A® 
system  may  significantly  impair  this  approach.  More 
investigation  is  needed  to  determine  the  limit  of  IOCE 
utilization  in  the  9020A. 

Potential  memory  capacity  for  the  9020A  system  was  increased 
with  the  Model  08A®  storage  element,  but  the  08A  SE  was  not 
implemented  in  the  field.  Part  of  the  issue  was  diagnostics  for 
field  operations.  Two  08A  SE  are  used  at  NAFEC  without  any 
difficulties.  The  08A  SE  doubled  the  0.25  megabyte  capacity  of 
the  currently  used  Model  08®  SE.  The  08  SE  memory  speed  was  not 
increased  and  storage  interference  would  not  be  reduced  directly 
by  the  08A  SE. 

Advances  in  memory  technology  since  the  08A  design  offer 
three  distinct  advantages:  a)  cost,  b)speed,  and  c)  reliability. 

a)  Cost:  current  memory  costs  per  unit  capacity  are  a 
fraction  of  the  08A  costs.  Estimates  of  memory  cost  would 
include  a  one  time  engineering  and  programming  cost  of  $200K; 

$20K  for  each  storage  element  cabinet,  back  plane,  and  power 
supply;  and  memory  at  $10K  for  each  megabyte. 

b)  Speed:  speed  would  be  about  400  nanoseconds  per  8 
bytes  or  faster.  This  is  more  than  six  times  faster  than  the 
current  9020A  Model  08  SE  memory.  The  greatly  increased  speed 
would  not  improve  single  processor  performance  but  would  markedly 
reduce  storage  interference.  The  full  potential  of  IOCE  off¬ 
loading  of  40%  processing  capacity  for  the  9020A  could  be 
realized.  The  reduction  of  the  current  estimate  of  10  to  20%  for 
200  track  load  storage  interference  would  be  added  to  the  IOCE 
off-loading  capacity. 

c)  Reliability:  error  correcting  circuits  and  built-in 
diagnostics  are  extremely  reMable.  Diagnostics  for  the 
multiport  switch  could  be  built-in,  or  possibly  existing 
diagnostics  could  be  used. 

Processing  capacity  would  also  become  greater  by  increased 
memory  capacity  which  could  eliminate  swapping  and  allow 
algorithmic  trade-offs  of  processing  capacity  for  memory 
capacity.  Eliminating  swapping  of  the  program  should  give  more 
than  a  10%  improvement  at  a  200  track  load.  Algorithmic  trade¬ 
off  would  have  to  be  studied  carefully,  but  20%  or  greater 
improvement  would  not  be  unusual. 

Eliminating  program  element  swapping  and  existing  storage 
element  interference  might  give  a  30%  processing  capacity 
improvement.  This  would  be  without  extensive  software  changes  as 
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might  be  incurred  in  IOCE  off-loading.  Simulations  could  be 
employed  to  further  investigate  the  potential  of  faster  and 
increased  memory  for  the  9020A®. 

Another  possible  product  of  recent  technology  is  the  use  of 
primary  memory  technology  for  secondary  memory  devices  such  as 
disks.  This  would  be  a  pseudo  disk  with  zero  rotation  latency 
and  microsecond  access  time.  Data  transfer  would  be  from  memory 
to  memory.  No  overruns  would  occur.  Transfer  could  be 
interrupted.  Transfer  would  be  at  the  maximum  speed  determined 
by  the  IOCE.  Thus  disk  accesses  would  be  reduced  from  almost  a 
tenth  of  a  second  to  microseconds. 

The  estimated  cost  of  the  memory  extendor  approach  would  be 
a  one-time  $100K  engineering  and  programming  cost;  $10K  for  each 
pseudo  device  for  cabinet,  rack,  and  power  supply;  and  $10K  per 
megabyte  of  capacity.  Typically,  an  eight  megabyte  capacity  per 
device  is  the  limit  of  current  off  the  shelf  products. 

This  last  approach  should  work  well  with  the  9020D®  system 
to.  reduce  swapping  response  time  without  increasing  memory 
capacity.  The  9020A  system  would  possibly  not  be  improved  due  to 
its  other  limitations.  Simulation  could  also  explore  the 
benefits  of  the  memory  extendor  enhancement. 

Many  alternatives  are  available  to  enhance  the  capacity  of 
the  9020®  Systems.  If  needed  these  alternatives  could  increase 
the  capacity  to  meet  the  increased  traffic  growth  and  NAS 
software  improvements  until  1990.  None  of  the  alternative 
enhancements  would  change  the  basic  architecture  of  the  current 
NAS  En  Route  Systems.  Thus  baseline  transition  possibilities 
will  not  be  significantly  impacted  by  possible  enhancements. 

C . 7  PROJECTED  NAS  EN  ROUTE  CONFIGURATIONS  FOR  THE  LATE  1980 's 

To  validate  baseline  assumptions,  projections  were  made  of 
current  planning  to  determine  how  the  NAS  En  Route  System  would 
evolve  by  1985.  These  projections  included  system  performance 
and  peak  traffic  loads.  Figure  C-7  illustrates  the  expected 
evolution  of  current  plans.  The  PAM  designates  the  replacement 
of  the  current  PAM. 

Examination  of  the  configuration  in  Figure  C-7  suggests  the 
possible  incorporation  of  the  NADIN  processor,  the  data  receiving 
group,  and  the  PAM  replacement  into  a  single  communications 
processor.  A  possible  configuration  is  illustrated  in  Figure  C- 
8.  This  configuration  would  consolidate  the  communications 
functions.  Additionally  DARC  has  ready  communication  paths  to 
the  9020  and  ETABS. 

A  more  difficult  and  significant  change  of  current  plans 
would  be  to  replace  the  CDCs  and  DCCs  with  an  upgraded  DARC 
system  and  use  a  central  communications  processor.  Most  of  the 
architectures  considered  as  replacements  for  the  NAS  En  Route 
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FIGURE  C-8  COMMUNICATION'  PROCESSOR  CONFIGURATION 
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System  have  a  decentralized  display  support.  The  DARC  system 
would  be  upgraded  in  the  display  processor  area  with  one 
processor  and  display  generator  for  each  PVD.  The  simple  star 
topology  of  the  resulting  configuration  would  isolate  the  9020® 
system  and  facilitate  its  wholesale  or  evolutionary  replacement. 

One  such  transition  configuration  is  depicted  in  Figure  C-9. 
Although  such  considerations  may  be  premature,  the  potential 
advantages  of  such  configurations  should  be  explored  further. 

The  projection  of  current  plans  to  the  configuration  in 
Figure  C-7  is  compatible  with  the  assumed  baseline  functions. 
Other  possible  En  Route  configurations  are  not  expected  to  change 
the  basic  system's  architecture. 

C . 8  SUMMARY  AND  CONCLUSIONS 

Summary 

The  order  of  magnitude  of  the  accuracy  for  the  functional 
processing  load  estimates  has  been  verified  for  the  functions 
which  were  common  to  the  measurement  data  on  the  NAS  En  Route 
Stage  A  System  Version  3d2.1. 

The  peak  traffic  loads  for  the  busiest  9020A®  and  9020D® 
ARTCCs  were  estimated  through  1990.  The  ability  of  the  9020s  to 
meet  the  projected  traffic  was  surveyed.  Alternatives  for 
enhancing  the  9020  CCC  performance  were  reviewed.  Projections  of 
how  the  ARTCC  configuration  would  evolve  in  the  late  1980's  were 
made. 


Conclusions 

The  functional  processing  load  estimates  are  accurate  to 
within  an  order  of  magnitude. 

The  En  Route  System  in  the  late  1980’s  will  be  very  similar 
to  the  current  system. 

The  busiest  9020A  ARTCCs  will  require  some  enhancement  of 
the  9020A  hardware  to  meet  peak  traffic  loads  projected  for  the 
late  1980's.  These  possible  enhancements  will  not  affect 
baseline  replacement  considerations. 

More  performance  measurement  and  analysis  of  the  current  NAS 
En  Route  System  are  needed  to  accurately  predict  system  capacity 
and  pew  traffic  loads. 


FIGURE  C-9  TRANSITION  CONFIGURATION 
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